From owner-doc-jp@jp.freebsd.org  Mon Apr  6 02:31:22 1998
Received: by jaz.jp.freebsd.org (8.8.8+3.0Wbeta7/8.7.3) id CAA24921
	Mon, 6 Apr 1998 02:31:22 +0900 (JST)
Received: by jaz.jp.freebsd.org (8.8.8+3.0Wbeta7/8.7.3) with ESMTP id CAA24911
	for <doc-jp@jp.FreeBSD.ORG>; Mon, 6 Apr 1998 02:31:17 +0900 (JST)
Received: from amont.astec.co.jp (amont.astec.co.jp [172.20.10.1])
	by tokyonet-entrance.astec.co.jp (8.8.8+2.7Wbeta7/3.6W-astecMX2.3) with ESMTP id CAA28954
	for <doc-jp@jp.FreeBSD.ORG>; Mon, 6 Apr 1998 02:31:15 +0900 (JST)
Received: from localhost (elpibe.astec.co.jp [172.20.21.82])
	by amont.astec.co.jp (8.7.6/3.6Wbeta5-astecMX2.4) with ESMTP id CAA09668
	for <doc-jp@jp.FreeBSD.ORG>; Mon, 6 Apr 1998 02:31:14 +0900 (JST)
To: doc-jp@jp.FreeBSD.ORG
From: Hiroyuki HANAI <hanai@astec.co.jp>
X-Mailer: Mew version 1.92.4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
	boundary="--Next_Part(Mon_Apr__6_02:28:48_1998_809)--"
Content-Transfer-Encoding: 7bit
Message-Id: <19980406023113E.hanai@astec.co.jp>
Date: Mon, 06 Apr 1998 02:31:13 +0900
X-Dispatcher: imput version 971024
Lines: 776
Reply-To: doc-jp@jp.freebsd.org
Precedence: bulk
X-Distribute: distribute [version 2.1 (Alpha) patchlevel=24]
X-Sequence: doc-jp 4545
Subject: [doc-jp 4545] Forward: Re: 2nd Newsletter (finally!) due to go to press in 10 days. 
Errors-To: owner-doc-jp@jp.freebsd.org
Sender: owner-doc-jp@jp.freebsd.org

----Next_Part(Mon_Apr__6_02:28:48_1998_809)--
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

$B$d$C$H>iCL$A$c$^$+$i869F$,Mh$^$7$?!#(B
$B$H$$$C$F$b!"40A4$J$b$N$G$O$J$/!"$^$@(B
$B8e$+$iDI2C$,$"$k$_$?$$$G$9!#(B

$B$H$O$$$C$F$b;O$a$i$l$k$N$G!"AaB.;O$a$^$;$&!#(B

$B:#2s$bNc$K$h$C$FAa$$%b%s>!$A!"$H$$$&$3$H$G!#(B

$B;d$O(B isp $B$r$b$i$$$^$;$&!#(B

$B%5%$%:(B $B%U%!%$%kL>(B	$BC4Ev<T(B
  7412 TCJA
  3241 coda
  5899 dillon
  3450 fnla
  7684 isp		$B$O$J$$(B
  8522 martin


$B$O$J$$(B

----Next_Part(Mon_Apr__6_02:28:48_1998_809)--
Content-Type: Message/Rfc822
Content-Transfer-Encoding: 7bit

Return-Path: <jkh@time.cdrom.com>
Received: from amont.astec.co.jp (amont.astec.co.jp [172.20.10.1])
	by elpibe.astec.co.jp (8.8.7/3.6W-elpibeMX1.0) with ESMTP id TAA10172
	for <\hanai@elpibe.astec.co.jp>; Sun, 5 Apr 1998 19:33:58 +0900 (JST)
Received: from tokyonet-entrance.astec.co.jp (tokyonet-entrance.astec.co.jp [172.20.10.6])
	by amont.astec.co.jp (8.7.6/3.6Wbeta5-astecMX2.4) with ESMTP id TAA26015
	for <hanai>; Sun, 5 Apr 1998 19:33:59 +0900 (JST)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
	by tokyonet-entrance.astec.co.jp (8.8.8+2.7Wbeta7/3.6W-astecMX2.3) with ESMTP id TAA10898
	for <hanai@astec.co.jp>; Sun, 5 Apr 1998 19:33:52 +0900 (JST)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1])
	by time.cdrom.com (8.8.8/8.8.8) with ESMTP id DAA02903
	for <hanai@astec.co.jp>; Sun, 5 Apr 1998 03:33:46 -0700 (PDT)
	(envelope-from jkh@time.cdrom.com)
To: Hiroyuki HANAI <hanai@astec.co.jp>
Subject: Re: 2nd Newsletter (finally!) due to go to press in 10 days. 
In-reply-to: Your message of "Mon, 23 Mar 1998 12:02:24 +0900."
             <19980323120224P.hanai@astec.co.jp> 
Date: Sun, 05 Apr 1998 03:33:46 -0700
Message-ID: <2899.891772426@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>

> When is it available?
> We are very glad if you sent it to me before announcement and we
> began translation.

Here is the first set of articles.  Note: This is _not the complete
newsletter_!  It is merely the first group of articles to be edited
and gotten ready for print.  We'll probably add about 2 more articles
and some text from Walnut Creek CDROM before we're finally ready, at
which point I can give you the complete set.  This is just to give
you a small head-start. :-)

Regards,

					Jordan

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	TCJA
#	dillon
#	isp
#	coda
#	fnla
#	martin
#
echo x - TCJA
sed 's/^X//' >TCJA << 'END-of-TCJA'
XTitle:	Getting kids on the Web with TCJA
XAuthor:	Wilko Bulte <wilko@tcja.nl>
X
XWhat is TCJA?  TCJA is the Technisch Creatief Jeugdcentrum Arnhem (or
XTCJA for short) in Arnhem, The Netherlands.  TCJA loosely translates
Xto "Technical and Creative Youth Center."
X
XThe TCJA is a foundation, in existence for over 25 years, that has the
Xgoal of popularizing scientific and technical subjects for kids from
X10-20 years of age.  Emphasis is put on getting women into the TCJA's
Xactivities since, in the Netherlands, women in technical or scientific
Xdisciplines are a very rare phenomenon. In fact, the influx of
Xstudents in almost all technical studies has been declining over the
Xpast few years.
X
XWe try to archive our goals in ways that kids appreciate, not putting
Xthem into class rooms but giving them instead the opportunity to
Xobtain hands-on experience with the subjects at hand.  Subjects range
Xfrom chemistry, photography, electronics, silk screen printing, wood
Xand metal working, and last but not least computer related fields.
X
XIn order to make all this possible, TCJA has their own (rented..)
Xbuilding with a small paid and a much bigger unpaid volunteer staff.
XMoney and equipment is donated by the government, companies and
Xindividuals.  TCJA is currently struggling to get enough funds
Xtogether to survive, so please feel free to donate funds if you feel
Xour efforts make sense.
X
XComputers at TCJA
X-----------------
X
XAs we've already mentioned, a lot of equipment is donated and our
Xcomputing infrastructure is no exception to this rule.  We run a
Xthinwire ethernet network with Cabletron hubs that connects all
Xsystems to a single LAN. The network involves 6 Sun SparcStation IPC,
Xa Sun SparcServer 4/470 and 9 486DX and one 386DX based PC machine.
XThe Sun machines were a gift from Philips Electronics and Sun
XNetherlands, the PCs were partially bought and partially donated by
XDigital Equipment. We even have Sun equipment that was donated by a
Xgenerous guy in California (thanks Gary!)
X
XIn this network 5 tabletop 486DX2/66 boxes run MS Windows for Workgroups
Xand Netscape Navigator for Web acces, a 486SX33 runs our administration 
X(also with WfW). A 486DX/33 is run with MS DOS to allow computer-aided
Xprinted circuit design. 
X
XThe remaining 2 PC machines are more interesting, they both run
XFreeBSD 2.2.1-Release. Both boxes are 486DX/33 EISA based Philips
Xservers. One of them is dedicated to NFS serving both the Sun boxes
Xand (using Samba) the PCs with WfW. The Sun SparcServer 4/470 is also
Xrun as an NFS server, it also handles the diskless boot of the Sun
XIPCs. All Suns run SunOS.
X
XThe other one is the more interesting one: it is our gateway to the
XInternet. It has been dubbed 'dontpanic.tcja.nl', a name taken from
Xthe cover of the Hitchhiker's Guide to the Galaxy (although we admit
Xwe christened it this way in the hope it will live up to it's
Xname. Sofar it has done so brilliantly)
X
XDontpanic has recently been upgraded from a 28K8 modem to an ISDN/PPP
Xlink using a Teles 16.3 interface board. Since all our Sun and PCs
Xtend to be run at the same time, especially in weekends, we are
Xrunning a caching Apache proxy server on it to limit actual ISDN/PPP
Xlink traffic as much as possible. The ISDN link uses the bisdn/ppp
Xpatch package which we adapted slightly for our specific needs. The
XISP runs Silicon Graphics machines, by the way.
X
XTo protect our network from the evil outside world (and probably also
Xto keep our adventurous kids from hacking on the Internet too much ;-)
Xdontpanic runs a customised version of the TIS firewall tool kit in
Xaddition to a set of ipfw filters using FreeBSD's kernel based
Xfirewall.  Apart from its networking duties, dontpanic also serves as
Xour local mailhub (POP for the PC Eudora or Netscape clients, NFS mail
Xspool for the Suns), a local Apache Web server (more on our Web stuff
Xin a moment), a local DNS server and as the printhost for an Apple
XLaserWriter postscript laserprinter (again with Samba for the WfW
Xclients, and lpd for the Sun/FreeBSD machines).  It's perhaps not
Xentirely recommended to have all these functions running on the
Xfirewall box, but we have to use what we have in this case.
X
XWe are currently in the process of migrating all our Sun disk storage
Xto SCSI disks, the Sun server used to have 6 900Mbyte SMD disks and
Xone 1.3Gb IPI disk. For reasons of power consumption and heat
Xproduction, donated SCSI disks are taking their place.
X
XOur Web presence
X----------------
X
XAn organisation like ours of course also must have it's own Internet
Xdomain registration and a Web server. Thanks to some kind souls a
X386DX/40, 8 Mbyte and 300Mb ESDI disk now lives under the name of
Xwww.tcja.nl It is of course also running FreeBSD, 2.1.0R in this
Xcase. Because it is 20 miles away we tend to leave it alone as much as
Xpossible. So far, only a single unscheduled intervention has been
Xneeded after a machine failed to reboot properly after a power
Xfailure.
X
XAlthough the previous hardware description probably sounds like a
Xsorry excuse for a webserver we have (knock on wood) impressive
Xuptimes to report.  As of today it has an uptime of 112 days, and that
Xis only because it had to be powercycled to add an UPS.  Uptime before
Xthe UPS was also 100+ days.
X
XIt is well connected to NLnet, being almost on the NLnet backbone at
Xthe Nijmegen University. So please feel free to take a look at
Xhttp://www.tcja.nl . It is mostly in Dutch, but an English abstract
Xhas been provided and quite some photographs help to get the idea
Xacross.
X
XIf you are interested in the quality of the power grid in Nijmegen you
Xcan ask our intelligent UPS by checking http://www.tcja.nl/ups . A
XJava applet will draw you diagrams of the previous 7 days.
X
XApart from (Apache) serving our web pages, the machine also handles
Xour email traffic. All mail to tcja.nl is UUCP-queued at www.tcja.nl
Xand grabbed from there by dontpanic.tcja.nl whenever the ISDN/PPP link
Xis up. This may sound a bit strange to US-based people, but there is
Xno such thing as a free permanently connected phone/ISDN line here in
Xthe Netherlands. You always pay a metered fee, so queueing is the
Xanswer if you don't want to go bankrupt.
X
XOur experiences with FreeBSD
X----------------------------
X
XSo, what do we think of FreeBSD? You've probably guessed it already:
Xwe are more than just a bit happy with the performance and reliability
Xof FreeBSD. We started in the dark ages with 386BSD 0.1 + patchkit,
Xand have never regretted doing so.
X
XIn the course of events a considerable number of people that saw our
Xsetup work in the way described have converted to FreeBSD. This
Xincluded a number of Linux adepts but also WinNT users are currently
Xcontemplating the move. You could say we act as a technical evangelist
Xgroup that can show a proven track record in the use of FreeBSD.
X
XFreeBSD has proven to be very stable, adaptable to local needs (thanks
Xto the availability of source code) and economical. Even with our
Xsometimes questionable and limited hardware resources the reliability
Xof the total system has proven to better than commercial operating
Xsystem offerings.
X
X[ sidebar ]
XAny questions about this article, general remarks, or even a proposed
Xdonation of equipment or money to the TCJA can be sent to
X
XWilko Bulte (wilko@tcja.nl) 
XRene de Vries (rene@tcja.nl)
X
XStichting Technisch Creatief Jeugdcentrum Arnhem
XArnhem, The Netherlands			http://www.tcja.nl
X[ /sidebar ]
X
END-of-TCJA
echo x - dillon
sed 's/^X//' >dillon << 'END-of-dillon'
XTitle: FreeBSD #1 for ISPs!
XAuthor: Matthew Dillon
X        Best Internet Communications, Inc.
X
XFor the typical modern ISP, the clock probably started running a bit
Xover 2 years ago.  Sure, there are plenty of older ISPs, but few of
XTHEM have had to contend with 100%/month growth, most of the larger
Xones also starting more as BBS systems then ISPs.  If you were like
Xus, however, you started right as the Internet really started to
Xbecome popular and that meant having to subsequently deal with the
Xstrain of very rapid growth.
X
XFor us, 2 years ago was indeed the beginning.  We had made an educated
Xguess as to our best market, hit it running, and turned out to be
Xright.  With that out of the way, the name of the game for BEST
XInternet was to simply survive the engineering and programming feats
Xrequired to support a rapidly exploding user base.
X
XIn the very beginning, we used BSDI and FreeBSD, and if the times had
Xbeen less trying wouldn't have made the almost fatal mistake of
Xshifting to larger multi-processor mini's from a brand-name UNIX
Xvendor who shall remain unidentified.  We somehow convinced ourselves
Xthat moving to larger commercially-supported boxes would both help
Xsell our service and provide adequate margins for growth.
X
XThe mistake almost drove us out of business.  The scalability never
Xmaterialized and the work required to maintain the minis went from
Xdifficult to near impossible.  Every hardware addition required a
Xridiculous amount of work and money to install.  We couldn't get bug
Xfixes for weeks or months.  There were all sorts of odd licensing fees
Xthat made it impossible to ""genericize"" machine installations.  I will
Xspare you the rest of the gory details.  It wasn't a pretty scene.
X
XIt was a nightmare made even worse by the fact that so many resources
Xwere concentrated in the minis that a crash, software problem,
Xinternet attack, or user mistake could effectively take down our
Xentire service.
X
XThis situation convinced the entire BEST Engineering department that
Xminis, the so called ``enterprise servers'', are a huge mistake.  To
Xmake a mini cost effective would require decking each one out with
Xhalf a million dollars worth of hardware and disk and then to actually
Xuse it would require putting a lot of marbles in one bag, so to speak.
X
XIn moving back to running FreeBSD on rack-mounted Pentium Pro 200's,
Xthere were a couple of issues that concerned us and a couple that did
Xnot.  We knew that the reliability was there, especially with PPro
X200's with their integrated ECC and secondary caches.  We had also
Xlearned that the governing limitation to all ISP support boxes is disk
XI/O, disk I/O, and disk I/O.  (Short of putting 10 SCSI interfaces in
Xeach of the two mini computers, the ten FreeBSD boxes that replaced
Xthem would win hands down).  We also knew that CPU power would not be
Xfactor and, indeed, it hasn't been - the new machines usually hit
Xphysical disk I/O limits long before the CPU saturated.  Finally, we
Xknew that we could balance out and tune CPU-verses-disk I/O by adding
Xmemory since the PPro motherboards could accommodate up to 512MB of ram
Xwhere we expected to need only 192MB in the absolute worst case.  Most
Xof shell boxes run with 128MB just fine, supporting up to 2000 user
Xaccounts on each.
X
XWhat we were worried about was that the maintenance required to
Xsupport a larger number of smaller boxes would increase.  In fact, the
Xtime required to maintain 24 PPro 200-based FreeBSD boxes has occupied
Xless than half the time we spent dealing with the two minis and
Xplethora of smaller vendor boxes, something which mainly possible
Xbecause every single FreeBSD box is configured and updated from a
Xtemplate machine. That's also something we just couldn't do with the
Xvendor boxes due to the massive customization each one required and
Xodd licenses that caused us to try to be frugal in regards to
Xinstallations.
X
XFreeBSD has also done an excellent job with service-specific boxes
Xsuch as our newsfeeds box, our newsreader boxes, our sendmail back-end
Xboxes, and other various administrative-duty machines.  Since the
Xsingle largest cost for an ISP-capable rack mount PC is usually the
Xdisk drives, most of the non-news auxiliary boxes are incredibly cheap
Xbecause they require no real disk storage.  Whereas a shell machine
Xwill have a 4G and two 9G disks to start out with, a proxy box
Xgenerally requires only a single 4G disk.  The ability to flexibly
Xtailor PC hardware configurations to specific tasks can lead to some
Xincredible cost savings without impacting maintainability.
X
XUltimately, the KISS principle applies.  No (major) NFS mounts, no
Xattempt to allow users to log into just any shell machine - we assign
Xthem one and that is where their account resides.  No attempt to slave
Xnews, each newsreader box is self contained and users pick one and
Xdon't switch.  We were worried that the load would not balance well.
XIn fact, it balances extremely well for all of that.  Sure, some shell
Xmachines are loaded a bit more then others, but if it isn't noticeable
Xit isn't a problem.  It is, perhaps, a somewhat different approach to
Xthe concept of a ``distributed system'', but it works, nonetheless,
Xand works very well.
X
XWhereas we used to get a cascade of complaints when some part of the
Xsystem would crunch, now we get only a few.  Where we used to have a
Xdifficult time working out the logistics of when to purchase a new
Xmachine or when to add a disk, now it becomes trivial because the
Xuser base on each machine builds, then matures, then... that's it, we
Xgo onto the next machine.  We stay one or two boxes ahead of the
Xgrowth curve and everything runs smooth as glass.
X
XI think it would be fair to say that FreeBSD not only saved us from
Xpast mistakes, but now empowers us to continue building our business
Xat whatever rate we choose.
X
XMatthew Dillon
XEngineering, BEST Internet Communications, Inc.
X
END-of-dillon
echo x - isp
sed 's/^X//' >isp << 'END-of-isp'
XTitle:  Another FreeBSD Success Story: An ISP is revolutionized
XAuthor:	Dan Benjamin
X
XAs a Network Analyst and an Intel UNIX Systems Manufacturer, being
Xable to offer my clients a wide variety of options is always a
Xpriority.  Most of my clients are companies who need servers,
Xworkstations, and support or consulting work like network analysis,
Xsetup, and administration.  Few companies I deal with have an
Xunlimited budget -- on the contrary -- one of the most challenging
Xaspects of this business is stretching the dollar.  In many cases, my
Xclients incorrectly believe that they need to spend a inordinate
Xamount of money to purchase a high-end server.  A FreeBSD server built
Xwith fault-tolerant components has, in my experience, always proved to
Xbe a excellent, cost-cutting solution to this problem.
X
XReal Life Example: A local ISP and Web presence provider was growing
Xrapidly.  They were adding clients regularly and new businesses were
Xsigning up on an almost daily basis.  They had recently upgraded their
Xbandwidth and were renting larger office space in a better location.
XHowever, they quickly found that their servers, primarily three
Xoverloaded Macintoshes, just couldn't cut it, even with memory and
Xprocessor upgrades.  The client was concerned that the price tag for a
Xnew, high-performance server to handle their DNS, Web access, FTP, and
XE-mail services would be too high.  Despite the new business, they
Xdidn't have an unlimited budget but also couldn't afford not to have a
Xfast machine that could deliver rock-stable performance.  FreeBSD was
Xthe answer.
X
XThis company was a Macintosh shop from the ground up, save for one PC
Xrunning Windows 95.  They did (and still do) all of their graphic
Xdesign, web, and paper advertising for themselves and for clients
Xusing Macintosh computers.  With this in mind, I knew that convincing
Xthem to switch server operating platforms could be a difficult task.
XIn past situations, moving a client site from an aging SunOS, NT, or
XNovell network to a FreeBSD managed one was a relatively
Xstraightforward task.  In many cases it was a simple matter of the
Xclient adjusting to a slightly different flavor of UNIX.  In others,
Xthe client might opt for remote network management or hire a full-time
XUNIX-savy administrator.  In any case, the transition was usually
Xstraightforward and the performance improvements could be easily
Xmeasured.  The switch invariably meant a jump in productivity and a
Xdecrease in operating and upgrade costs.  Integrating a FreeBSD system
Xinto a pre-existing network is easy when you take advantage of the
Xnumerous applications available from the FreeBSD Ports collection.
X
XBut convincing this all-Macintosh shop to switch hardware platforms
Xand operating systems in one motion wouldn't be easy.  This client
Xwould literally need to shut down their dependable (albeit slow)
XMacintosh servers and put their faith in an architecture that had
Xslowly eroded the Mac's place in American computing.  A difficult
Xtask.
X
XFortunately, establishing FreeBSD's rock-solid stability proved to be
Xan easier than expected task: As this client conducted most of its
Xbusiness on the Internet, they had all used Yahoo extensively - both
Xto research and locate information, as well as to publicize and
Xadvertise for themselves and their clients.  What they didn't know was
Xthat Yahoo used FreeBSD almost exclusively (see FreeBSD News, Issue
X1).  Once they learned that FreeBSD also powered ftp.cdrom.com, their
Xdecision to switch became even more clear.  In addition, the company
Xpresident, also a Macintosh user and fan, was actually in favor of
XFreeBSD running their on-line business - he knew it would mean
Ximprovements in speed and reliability because of his background with
XBSD UNIX networking.
X
XBut what about the people "in the trenches", the designers and
Xdevelopers who would need to access and update the Web sights on a
Xdaily, even hourly basis.  How would a FreeBSD server change their
Xworld?  There were several legitimate concerns, first and foremost,
Xhow would the developers interface with the new server?  Using ftp was
Xnot an option - that method was cryptic and went against the grain of
Xthe Mac user's mind set.  Drag and drop, double click, theirs is the
Xworld of the original GUI.
X
XFortunately, Research Systems UNIX Group (RSUG) at the University of
XMichigan has developed Netatalk, which provides access to the UNIX
Xfile system for Macintosh and other systems with AppleShare client
Xsoftware.  Simply put, Netatalk is a file and print server for
XAppleTalk networks and is available for FreeBSD from the Ports
Xcollection.  Installing software from a FreeBSD Port is usually as
Xsimple as downloading a tar file (or, if you already have the ports
Xcollection loaded, simply going to the right directory) and typing
X"make install".  A few changes to some configuration files, and a
Xquick restart of inetd, and the Macs were again dragging and dropping
Xto their hearts content.  I used Samba, a networking package created
Xby Andrew Tridgell - also available as a FreeBSD port - to provide
Xconnectivity to the Windows 95 machine.
X
XAfter transitioning DNS, the next - and most important step was
Xtransitioning the web sites.  At that time, the server was a Pentium
X160 with 32MB memory and several SCSI drives.  It ran FreeBSD-Release
X2.1.7 and an early Apache Web server.  The performance improvements
Xwere impressive, to say the least, and it wasn't long before all of
Xthe sites were moved.  Mail and FTP services quickly followed, and
Xeventually the single FreeBSD server had completely replaced several
XMacintosh servers.
X
XThe introduction of the server brought a higher level of security in
Xaddition to performance improvements.  I'd taken several measures with
Xsendmail to prevent spamming and relaying - something that had plagued
Xthem in the past.  I'd also installed the TCP Wrappers port which
Xhelps prevent unauthorized access to well-known services, and several
Xother security tweaks - all for the cost of a pre-configured FreeBSD
Xserver.
X
XSince then, I've installed several more servers and replaced the
Xinitial server with a Pentium II Pro running FreeBSD 2.2.5-Stable
X(pre-2.2.6). Internally, their network has never been faster, but
Xtheir clients - to whom the upgrades have meant the most - are quite
Xhappy with the improvements in speed and the lack of downtime.
XMost recently, we added an NT server to handle active server pages.
XIt coexists with FreeBSD rather well, sharing with it the dynamic
Xcontent of a backend SQL server.
X
XAnd this is just one example.  Most of the server solutions I provide
Xto my clients are running FreeBSD, all with excellent results.
XAnother recent project involved the placement of a dual-homed,
Xmirrored and security-hardened FreeBSD mail server to filter spam and
Xdeny relaying.  Beneath their firewall sit several more FreeBSD
Xservers to handle internal pop mail and fileserving across the WAN.
X
XBut lest we forget, FreeBSD also isn't just a server.  The FreeBSD X
XWorkstation I'm sitting in front of now allows me to run StarWriter 3,
Xwith it's MS Word-like interface, to compose this article.  I manage
Xmy business finances and client lists with databases that run on
XFreeBSD and we even do graphic design (with the Gimp port) and Java
X(with the JDK 1.5 port), all using FreeBSD.
X
XOverall, although I use it on a daily basis within my own business,
XFreeBSD has had it's greatest impact on my clients in the hardware and
Xconsulting business.  I can provide them with reliable servers and
Xworkstations that guarantee the performance and reliability my clients
Xrequire.  And because FreeBSD is free, I can pass that as a savings on
Xto my customers.
X
X
END-of-isp
echo x - coda
sed 's/^X//' >coda << 'END-of-coda'
XTitle: Coda on FreeBSD
XAuthor: M. Satyanarayanan
X        School of Computer Science
X        Carnegie Mellon University
X
XWe  are  pleased  to  inform  the FreeBSD community that the Coda File
XSystem is now available for FreeBSD 2.2.5 and 2.2.6.  Our hope is that
Xthe free availability of this state-of-the-art distributed file system
Xin source code form will attract serious users  and  developers  whose
Xtalents  will  enhance  the  system along many dimensions.  Since Coda
Xalso runs on NetBSD and Linux, we hope that over time it  will  become
Xthe distributed file system of choice for free Unix platforms.
X
XCoda  is  a  distributed  file  system  developed  at  Carnegie Mellon
XUniversity as a test  bed  for  research  in  replication  and  mobile
Xcomputing.    As  a  descendant  of  the  Andrew File System (AFS), it
Xinherits many  of  the  key  features  that  make  AFS  attractive  in
Xlarge-scale  distributed environments.  These include: a client-server
Xmodel  with  trusted   servers   and   untrusted   clients;   location
Xtransparency,   so  that  server  identities  are  completely  hidden;
Xaggressive on-disk whole-file client caching, with a further level  of
Xblock-level  caching  in  the  buffer cache; organization of data into
Xlogical  volumes  for  purposes  of  easy  system  administration;  an
Xaccess-list  model  of  protection;  and  a  user-level implementation
Xstrategy that keeps the entire server and all but a tiny  fraction  of
Xthe client out of the kernel.
X
XIn   addition,  Coda  provides  many  unique  capabilities  for  next-
Xgeneration wired and wireless environments.   These  include:  support
Xfor   voluntary  and  involuntary  disconnected  operation  (including
Xhoarding,  reintegration,   and   conflict-detection);   support   for
Xweakly-connected  operation with dynamic adaptation to network quality
Xranging from  modem  speeds  to  LAN  speeds;  transparent  optimistic
Xread-write  server  replication  of  data,  with support for directory
Xresolution and  application-specific  conflict  resolution.    Planned
Xenhancements   to   Coda   include  write-back  caching  for  improved
Xperformance while strongly-connected, and  integration  with  Kerberos
Xauthentication.    The  disconnected  operation capability of Coda has
Xserved  as  the  inspiration  for  the  IntelliMirror   component   of
XMicrosoft's forthcoming NT 5.0 file system.
X
XWe  invite  the FreeBSD community to join us in transforming Coda from
Xthe  experimental  prototype  that  it  is  now  to  a   high-quality,
Xwell-engineered  system  for  the  free  Unix  community.   The person
Xleading this  effort  is  Peter  Braam  (braam@cs.cmu.edu),  a  senior
Xresearcher  in  the  Coda  project  at  Carnegie Mellon.  Other people
Xcurrently involved in this work at Carnegie Mellon include Bob  Baron,
XHenry  Pierce,  Robert  Watson,  and  Jan  Harkes.    The full cast of
Xcontributors to Coda over its multi-year evolution is too long to list
Xhere.
X
XFor  further  details, visit the Coda Web page at www.coda.cs.cmu.edu.
XTo obtain research papers and PhD theses generated by Coda, follow the
X"papers"  link.    To learn more about the broader research context in
Xwhich Coda is being developed, follow the "Coda project" link.
END-of-coda
echo x - fnla
sed 's/^X//' >fnla << 'END-of-fnla'
XTitle:	FreeBSD powers hi-fi equipment
XAuthor: Oliver Fromme <olli@fromme.com>
X
XAt first sight, it looks like an ordinary audio CD player.  You put a
XCD into the tray, press the ``Play'' button; the tray closes, and it
Xstarts playing your favorite music -- for up to 11 hours per CD,
Xwhile displaying band names and song titles in the back-lit 150 x 32
Xpixels display.
X
XWhat kind of device is this?  It is a home-made MPEG audio player,
Xpowered by FreeBSD.  From a technical point of view, it is almost a
Xregular PC: a Pentium CPU, 32 MB of EDO RAM, a sound card, a network
Xinterface card, and a CD-ROM drive.  However, there are a few
Xsubstantial differences between this player and an ordinary PC.  First
Xof all, the primary goal was to make the device look like a piece of
Xhigh-end audio equipment, not like a PC.  Therefore, all hardware
Xcomponents have to fit into a regular CD player case, requiring a
X2/3-size Baby-AT mainboard, an ISA raiser-card for the sound card and
Xthe network interface card, and a slimline power supply.
X
XThe second (and not less important) goal was to make the player as
Xsilent as possible.  This means: no hard disk drive, no fans.  The
Xabsence of a hard disk is the most problematic restriction.  The
Xcurrent implementation boots from a FreeBSD server (which is located
Xin a different room) via a boot EPROM on the network interface card,
Xusing bootp and tftp protocols.  If this fails, the player boots from
Xan internal floppy disk drive, which takes considerably longer, so
Xthis is only meant to be used as an ``emergency fall back'', in case
Xthe player is used at a foreign location without access to the boot
Xserver.  Other possibilities, including booting from an EPROM or
Xflash-ROM card, have been considered and might be implemented in a
Xfuture revision of the player.
X
XNot allowing any fans is also critical.  The CPU is a Pentium-100,
Xrunning at 90 MHz with a large passive cooler, so no CPU fan is
Xrequired.  The power supply is a slimline 73W type that is small
Xenough to fit into the CD player case.  It does have a fan, but it
Xturned out to be possible to disable the fan without overheating the
Xdevice (the entire hardware consumes about 30W).
X
XWhy FreeBSD?  It features excellent stability, reliability, and
Xperformance.  The ability to track current developments and updates of
Xthe system's source tree easily and without risk is a valuable bonus.
XWriting device drivers for FreeBSD is fairly easy -- in this case, two
Xdrivers are required to access the LCD display (connected to the
Xparallel port, so a slightly modified ``lpt'' driver is sufficient)
Xand the receiver of the infrared remote control (connected to one of
Xthe serial ports).  The buttons on the CD player don't even require a
Xspecial driver, because they are connected to the keyboard input via
Xthe circuit board of a regular keyboard.  Almost all other software
Xalready exists for FreeBSD, such as the MPEG audio decoder (mpg123)
Xand a program to fetch MPEG files via the network using the HTTP
Xprotocol.
X
XWhile this MPEG audio player is a private project of mine that I'm
Xbuilding in my spare time, it clearly shows that FreeBSD is perfectly
Xsuitable for powering embedded applications and devices.
X
XReferences:
X - http://fromme.com/project/
X      Current state of the MPEG audio player project.
X - http://www.freebsd.org/
X      The FreeBSD homepage.
X - http://mpg.123.org/
X      Homepage of the ``mpg123'' MPEG audio player/decoder.
END-of-fnla
echo x - martin
sed 's/^X//' >martin << 'END-of-martin'
XTitle: How FreeBSD became the favorite OS on my desktop.
XAuthor: Martin Cracauer <cracauer@cons.org>
X
XI'm working for BIK - Aschpurwis + Behrens, a German Market- and
XMediaresearch institute (www.bik-gmbh.de). BIK used quite a lot of
Xdifferent Unix derivate, SCO, NeXTStep, SunOS, Solaris, NetBSD,
Xseveral PC-based SVR4 and, of course, FreeBSD.
X
XThe story how FreeBSD became the favorite OS on my desktop at work is
Xsomewhat boring and largely a matter of personal preference. FreeBSD
Xjust felt best for me and I had the fewest problems from all the Unix
Xderivates I tried. The only rival to this (for me) has been NetBSD.
X
XSomewhat less boring is how FreeBSD became the dominant computing
Xplatform for the company's multiuser and server machines.
X
XSince 1990, we developed a batch-oriented tabulation generator with a
Xlot of hooks for adding functionality. It became a pretty decent
Xproduct, though it remained hard to use for GUI-oriented users so only
Xa few outside customers used it directly. It ran on all the plaforms
Xlisted above.
X
XWhen the World Wide Web took off, we suddenly found ourself in a much
Xbetter position than those competitors who developed interactive
Xtabulation software on DOS/Windows or Macintosh. We could easily turn
XHTML forms input into definitions for our program and display the
Xresults in HTML.
X
XWhile the needed functionality was easily added, we faced major
Xperformance problems. What we found was that FreeBSD did an amazing
Xjob speeding up our application without major rewrites.
X
XFirst of all, our application was optimized to produce large
Xquantities of tables for lengthy printed reports. In the early 90's,
X30-45 minutes for such a run was considered a very good time. For the
XWWW-based world of 1996, we had much smaller tabulations to produce
Xand we set our limit to 7 seconds. That figure couldn't be reached
Xjust by using modern machines.
X
XWe faced three problems:
X
X- Some way had to be found to speed up getting just the portion of
X  data that was immediately needed so that the CPU could be kept busy
X  instead of waiting for the data to arrive from disk.
X
X- Our application not only uses large data sets but calls the C
X  compiler (including assembler and linker) two times on every
X  invocation.  Besides the cost of the compiler runs itself, we also
X  recognized that most systems would kick the main data set out of the
X  filesystem buffer cache during these compilations and so it would need
X  to be reread from disk again when another analysis was started.
X
X- We needed maximum disk thoughput, of course, and much more than the
X  best disks offered.
X
X- Our application isn't just one program, but a collection of a number
X  of connected programs that get restarted on every invocation. The
X  cost were negligible on a 30-minute analysis, but for the web-based
X  product we had to make sure we could start all these processes fast
X  enough. We also wanted to implement this as a CGI application, adding
X  even more process starts.
X
XOf course, all of these are problems which could probably have been
Xbest solved by changing our application, but doing so would also have
Xrequired valuable programmer hours which we really needed to apply
Xelsewhere.  Such resistance to "fixing" a application is also hardly
Xan atypical situation in almost any area of professional computing,
Xespecially when the application in question *works* (including HTML
Xsupport, which was added in no time).
X
XBelieve it or not, the operating system alone can solve many such
Xproblems without having to change the application, and FreeBSD
Xcertainly came to our aid here.
X
XThe first problem was that we read only small random portions from big
Xdata sets. All other Unix derivatives we tried could not deliver the
Xdata efficiently enough for our specific access patterns (which were
Xnot optimal, of course). The systems were either too often idle
Xwaiting for the disk or spent a lot of time in the kernel (obviously
Xmanaging caches and copying data). Many did both, and I won't even
Xstart talking about the various mmap() problems we found.  FreeBSD,
Xhowever, managed to deliver the needed pieces of data fast enough that
Xwe achieved 90% CPU time spent in our application. This was enough to
Xsave us from rewriting a critial part of the application.
X
XThe next problem was that our application calls the C compiler before
Xand after accessing the main data set. On all other systems we tried,
Xthe result was that the compiler runs caused the data set to be
Xremoved from the disk cache so that subsequent application runs on the
Xsame data had to get it from the disk again, resulting in a large
Xperformance hit. Adding memory didn't even seem to help much, these
Xsystems just seemed not to like keeping big files cached when smaller
Xones were being accessed and nothing could be done to tell them
Xotherwise.  Using these systems, we first thought we'd have to develop
Xa special program to hold the data set in memory and provide it to the
Xtabulation generator via shared memory. Since more than one data set
Xresides on a machine and one shouldn't keep all memory for itself,
Xwe'd basically need to reimplement the job of an operating system's
Xbuffer cache, simply with different preferences. A lot of work!
X
XHappily, all of this became a moot point under FreeBSD. On a FreeBSD
Xbox with 256 MB memory we can run multiple analysis on the same 212 MB
Xdata set and the file is still in cache after the compilation runs
Xbetween each analysis. Maybe this behaviour can potentially hurt the
Xperformance of other applications, but we didn't find any cases of
Xthis happening.  In this alone, FreeBSD saved us weeks of
Ximplementation, testing, performance analysis and tuning.
X
XDisk throughput is, of course, also critical to our task and we found
Xthat FreeBSD's ccd (disk striping) driver scales very well for us. If
Xwe add disks and controllers to a striped volume, the resulting
Xperformance out of the combined filesystem is pretty near the
Xsum-total throughput of single filesystems on individual drives.
XFrankly, we expected this to be much less.  For anyone requiring disk
Xthroughput over reliability, it is nonethless an important question to
Xask of those offering other RAID solutions: Assuming that they run
Xproperly at all, are they faster or slower than single disks?
X
XBesides its advantages in performance, we found FreeBSD to be the Unix
Xsystem that was most easily managed.
X
XWe often have to configure machines for additional web services and,
Xwhen we do, copying an existing FreeBSD installation is done in no
Xtime, mostly due to its simple disk volume management and the fact
Xthat all configuration is done via user-editable ASCII
Xfiles. Installing a new machine from scratch using sysinstall is also
Xeasy and fast, the result being already much more customized than many
Xother Unix system's installations leave them (network configuration,
Xthird-party-applications, all done in one pass).
X
XThe FreeBSD community is a major selling point, too. As of this
Xwriting, 5 people from the BSD user group Hamburg (www.bsdhh.org) have
Xjoined us as programmers and system managers. If you've already
Xexperienced trying to get good staff, you can imagine what the real
Xvalue is. And the FreeBSD mailing lists are an invaluable source of
Xinformation for many areas of professionaly computing.
X
XOf course, problems with FreeBSD exist, too. The dominant problems is
Xgetting reliable PC hardware. When I started using PC Unix in 1991, I
Xthought the situation was bad. Multiple busses, human-driver I/O
Xaddress management, heat problems etc. Guess what, it got
Xworse. Motherboards with just 64 cachable area, non-parity memory or
Xeven worse motherboards without parity support, broken PCI cards, bad
Xcases, broken power supplies and friends all cause our computing staff
Xto keep way too many things in their heads. Not to speak of explaining
Xall these to PC dealers.
X
XFor our GUI users, we also miss some of the commercial software one
Xcan get for the big vendor's workstations (although we're not sure
Xthey are worth the prices compared to MS-Windows applications anyway).
X
XOur own programming abilities have also improved through reading the
Xexcellent code in some of FreeBSD's subsystems and we are very happy
Xwith FreeBSD, only a few other machines having survived here.  As time
Xgoes on, FreeBSD's position here also gets only stronger as our
Xexperience using it and our familarity with the sources grows.  We
Xhope that you too will be motivated to try FreeBSD for your own small
Xbusiness or research project!
END-of-martin
exit


----Next_Part(Mon_Apr__6_02:28:48_1998_809)----
