Conference summaries from day one of BSDCan 2006, which was held on Friday 12 May 2006.
Back to the Future: BSD on the Edge of an Enterprise
Russell works for Computing and Network Services (CNS) at the University of Toronto and described how he is using FreeBSD in conjunction with Quagga for campus-wide edge routing. He also uses IPFW with dummynet for traffic shaping. Originally intended to serve as a stand-in between some Proteon gear being replaced, his solution has now been running for several years on off-the-shelf commodity Intel hardware, namely Dell PowerEdge 2650 rackmount servers.
His presentation described the intimate details of how routing is set up at the University; out of three edge routers, one of them (“Jura”) serves as the decision maker, and all outgoing packets travel to it initially. He then uses ipfw’s fwd capability to redirect the packets to the right destination (one of three links — two Cogent links, and one Internet2 link for inter-campus links). Finally he uses IPFW’s traffic shaping capabilities to nail down offenders who do things like trying to run a public RedHat mirror (in Mann’s case, he’s nailed down to 50 kbps.)
In closing Russell mentioned that he is more motivated by Scottish economics rather than any particular zealotry for or against Cisco/Juniper products. By Scottish economics he means that he can purchase a commodity box for $2-3k to do the job whereas buying Cisco gear would cost somewhere in the order of $13-30k.
Building a FreeBSD Appliance with NanoBSD
I’ve mentioned in previous years that Poul-Henning (phk) is a very entertaining speaker, and this talk was no exception. Poul-Henning spent the first part of the talk describing general strategies for building embedded appliances; others like Wes Peters have given their own perspectives on these issues. Pul-Henning’s main comment was that the #1 failure of embedded appliances is that “something stopped rotating”, ergo “rotation is bad”. This means that one ought to use flash devices instead of hard disks, minimize or eliminate cooling fans, and so on.
There are, of course, certain challenges with using flash devices for storage. They are indestructible in read-only mode, but will die after a certain number of erase operations. Poul-Henning argued that UFS is not necessarily the best solution for flash devices and challenged someone to write a filesystem optimized for minimizing writes to flash devices. Admittedly, flash devices often have an adaptation layer to optimize flash longevity by having a “bad sector replacement pool”, wear-leveling, etc. but it’s not a perfect solution.
He also talked about ways to communicate with the user when one does not have a video terminal for output. Flashing LEDs seems to be a good solution, and has himself written an led(4) driver to do just that.
Finally, he discussed his NanoBSD project, which is really just a stripped-down version of FreeBSD, with some special optimizations to deal with issues like flash wearout. For example, at an equilibrium state, everything is read-only; the system is (re)configured by mounting a special partition, /cfg, writeable, making the change, and then unmounting it. /etc is just a ramdisk created from the contents of /cfg at boot time.
Experiences Bringing FreeBSD/arm up on Atmel AT91RM9200
Warner Losh and Olivier Houchard
Continuing in the vein of using BSD for embedded devices, this talk was about adapting FreeBSD for a system-on-a-chip (SoC) device based around an ARM core. SoC devices come in many flavours, with varying features and peripherals (Ethernet controller, number of GPIO pins, etc.), amount of memory, etc. The main challenges appeared to be that the hardware was always changing, and that the vendor frequently changes the chip layout so the lifetime of a particular SoC device with a particular feature set and peripherals seems to be quite short. This may pose a problem for manufacturers that wish to produce an appliance built around SoC for several years.
Much of the work to port FreeBSD to the aforementioned device was just writing specialized device drivers and/or adapting existing ones for the hardware specifications. There has already been a lot of work done in the tree for other ARM-based embedded devices and Warner was able to use that work to help him along. He also gave credit to the ease of the cross-compilation environment in FreeBSD.
How the FreeBSD Project Works
Robert Watson gave an enlightening talk about the challenges faced by the FreeBSD project, trying to marshal 300+ developers worldwide into playing nicely with each other. He feels that by and large, most developers get along with one another, but of course there have to be some dispute resolution mechanisms. Additionally, the fact that the bar for admission into FreeBSD (as a committer, that is) is quite high, and depends a lot on peer review of one’s work and presumably one’s personality and/or social skills.
In the presentation he gave a quick overview of what the FreeBSD project produces in addition to the operating system itself, and talked a bit about the FreeBSD processes, covering anything from the release engineering cycle to conflict resolution. And, of course, he defined what a bikeshed is.
BOF: Open Source Alternatives to Microsoft Exchange
A BOF session was held on open source alternatives to Microsoft Exchange immediately after the last presentation. The short answer to the question of “what open-source software is out there that can be used to replace (or instead of) Microsoft Exchange but with the same feature set” seems to be “not much”. Although Exchange is a horrible burden to maintain, the advertised feature set is actually pretty good, and ultimately this is what drives businesses towards implementing Exchange.
According to Matt Schwartz (the organizer of the BOF), Zimbra is probably the front-runner in this category. There are two editions of Zimbra; the free, open source edition has fewer features (such as no direct integration with Microsoft Outlook). Another project which has some potential (according to him) is Hula, although given its Novell roots I wonder if it’s just Novell dumping the codebase from Groupwise onto an unsuspecting open source community (I don’t particularly wish to see the source code of Groupwise).