Ken Merry, a coworker at Spectra Logic, recently finished porting
SGI's "CAM Target Layer" (CTL) stack to FreeBSD current. When he
relayed his success to me, he qualified the accomplishment, "CTL's
good enough for us to include in a Spectra Logic product, but it
will need a lot of work before we can push CTL back into FreeBSD."
Ken's comment illustrates one of many challenges faced by commercial
users of FreeBSD: contributing code back to the FreeBSD community
often requires work outside the scope of your product. But even
before getting to this point, you must have a strategy for tracking
changes in FreeBSD, identify the additional resources needed to
manage FreeBSD as an "external vendor," and sell internally the
value of contributing back to FreeBSD.
Software Configuration Management
FreeBSD is a large and constantly evolving piece of software. During
a typical month, over a thousand changes will be committed to the
FreeBSD Subversion repository. Coupling FreeBSD with even a
moderately sized internal code base will quickly burn up developer
cycles if you don't have a well engineered solution for dealing
with this software configuration management problem. A successful
strategy will have the following minimum characteristics:
High fidelity tracking of the unaltered FreeBSD code. Doing periodic
imports of the FreeBSD source tree into a "vendor branch" of your
SCM system may be sufficient, but the ideal solution will preserve
each submission and all its state from the FreeBSD Subversion
repository. This facilitates selective incorporation of recent bug
fixes or cutting-edge features you may need in your product.
Tracking of FreeBSD's head branch in addition to the branch (e.g.
stable/8) on which the product will be based. The FreeBSD project's
timeline for incorporation of bug fixes and features into stable
branches may not match the release schedule for your product. Having
access to the head branch will allow you to define your own policy
for what to include in your product.
A separate branch which represents the customized version of FreeBSD
that will ship in your product.
The ability to selectively merge changes between the product and
The ability to easily migrate your private changes to a new FreeBSD
branch. Successful products have long lifetimes. Today's release
based on stable/8 will eventually be replaced by a release based
on the, yet to be created by the FreeBSD project, stable/9 branch.
Anticipating and planning for this transition upfront will greatly
reduce the effort to rebase your product.
Robust merging capabilities, and tracking of merged changes. This
item is critical, not only for managing repeated integrations of
functionality from FreeBSD, but also for dealing with "round-tripping"
of any changes you submit back to the FreeBSD project. When an
almost identical change (i.e. the change you've given back to the
project) is present in both the FreeBSD and product tree, the SCM
system will see this as two independently created but similar
changes. Pick a tool that minimizes the amount of manual merge
resolution required in this case.
At Spectra Logic, we prototyped solutions to this problem using
Git, Mercurial, and Perforce. During that process, I became convinced
that solutions using any of these three SCMs are possible. I'm
sure this holds true for SCMs we didn't evaluate as well. The
choice for your situation will be driven by needs outside the scope
of the import process: price, scalability, the need for a distributed
SCM, or a requirement to remain compatible with your existing SCM.
Regardless of what solution you pick be prepared to expend several
man weeks making it robust. For those using Perforce, I've
the solution we developed for that tool. As I become aware of other
solutions I'll add them to the same directory.
One quick note to FreeBSD developers on this topic. Whenever
possible, merge changes between FreeBSD branches using Subversion's
merge capabilities instead of manually transplanting a change by
applying a patch. Many tools for importing Subversion repositories
into other SCMs make use of Subversion's merge tracking data to
replicate merge history during the conversion. When this merge
history is present and preserved, the commercial user's SCM system
can intelligently avoid merge conflicts that would otherwise have
to be resolved manually; for example, when a bug fix is pulled into
a product release from FreeBSD current and then is later merged by
the FreeBSD project into the stable branch on which that product
Managing FreeBSD as a Vendor
With the mechanics of integrating FreeBSD code into your SCM out
of the way, it's time to find and devote the resources needed to
manage your FreeBSD vendor relationship. Having talked to lots of
organizations with my FreeBSD Foundation hat on, the default response
to the resource problem is to largely ignore it. The scenario goes
Imagine an amazing new product based on FreeBSD.
Take a snapshot of FreeBSD on which to build the product.
Focus 100% internally to develop and deliver the product.
Repeat #3 for several product releases.
Years later determine that taking your product to the next level
would greatly benefit from technology available in a newer version
of FreeBSD than you used in your snapshot.
Spend man years performing a "fork-lift" upgrade of your product to
a newer version of FreeBSD.
The time and energy of doing the periodic upgrades, although
considerable, doesn't account for all of the costs in this approach.
While "heads down" working on the product, opportunities to leverage
new developments in FreeBSD will be missed. If the upgrade cycle
is long, you may also find you've expended considerable internal
developer time re-implementing functionality already in FreeBSD;
functionality that will cause expensive conflicts when you move to
a newer version of FreeBSD.
The best way to avoid this expense and maximize the value of your
decision to use FreeBSD is to devote internal developer time to
tracking the FreeBSD project. The role of these individuals is to
not only understand changes in FreeBSD, but to also educate other
developers and management about the functionality in FreeBSD, explain
how best to utilize that functionality, and to keep everyone updated
on FreeBSD's "product roadmap". Your commercial vendors have field
application engineers that perform much of these tasks for you.
The Open Source model doesn't have the profits to provide these
services, so you must invest in your own people to fill this role.
One of the leading factors driving commercial users to choose FreeBSD
is the BSD license. What's yours is yours and you have every right
to keep it that way. However, there can be sound business reasons
that motivate you to release some of your innovations back to the
The code will be maintained by the FreeBSD project. This can free
up your developer resources to focus on features with more core
value to your product. Offloading the support of all but the code
surrounding your critical intellectual property can provide large
Contributing the code reduces the chance that a different implementation
of the same functionality will be integrated into FreeBSD. A
competing version of a feature will most likely cause conflicts
with the facility you're maintaining internally. Once this occurs,
you can either choose to migrate to the public implementation or
continue to support your own. Either choice is expensive.
Releasing the code has marketing value. This can be a way to promote
your business as OpenSource friendly or supportive of FreeBSD.
Releasing the code will allow you to collaborate with others and
create a feature you could not accomplish internally given your
staff or financial resources.
Desire to strengthen the utility of FreeBSD, growing it's appeal
to new users so its use increases and FreeBSD continues to be
available and supported by a healthy community.
Before trying to identify candidates for contribution to the FreeBSD
project, keep in mind that something good enough for your product
isn't necessarily ready to be given to the FreeBSD project. This
issue is at the core of Ken Merry's quote above. Before CTL, or
any contribution, will be accepted:
The contribution must have value to the community as a whole. For
example, a device driver for a piece of custom hardware you build
and embed in your appliance is not useful outside of your product.
There is no incentive for the FreeBSD community to take on the cost
of maintaining such a feature.
The contribution must be in a state where the FreeBSD project can
maintain it. The code must be well documented, conform to the
coding and documentation standards of the FreeBSD project, and any
necessary technical publications needed to augment or fix bugs in
the submission must be available.
You must engage the FreeBSD community about the feature or change
to ensure there is agreement that the above two requirements have
I've talked with many organizations that fully understand the
business case for contributing back code. They even dedicate some
portion of a few staff member's time to manage contributions. Their
failing is to believe that the job of meeting the above requirements
rests solely on the shoulders of these "liaisons to the FreeBSD
community." These liaison's role is to facilitate your relationship
with the FreeBSD community, but if you task them with taking any
random submission from the rest of your development staff and turning
into something that can be committed to FreeBSD, they will quickly
burn out, leave, or both. Instead you must train your whole staff
in the business value of writing code with best practices, that
meets the high standards of the FreeBSD community. These standards
yield high quality, maintainable code - the same attributes you
want in the code for your whole product. Submitting code to FreeBSD
then becomes a process of internal review and correction, followed
by external community review and correction all managed by your
on-staff community liaison, but powered by the continuous involvement
of the developer that originated the code. This is the only
sustainable way to gain the huge benefits of contributing code to
the FreeBSD project.
The FreeBSD Foundation's Role
The FreeBSD Foundation has helped countless organizations improve
their interactions with the FreeBSD community. If you are looking
to optimize your use of FreeBSD, we'd love to help. Every year
we visit universities and corporations, large and small, to help
them get the most out of FreeBSD. Let us know if we can add your
site to our calendar.
Why do we do it? A large part of our mission is to maximize the
utility of FreeBSD. Sitting down with folks doing innovative things
with this operating system is one of the best ways we can determine
where to invest next. Your success is FreeBSD's success, and we
are doing all that we can to ensure FreeBSD's success for decades
We're off to a great start having raised $48,000 from 226 donors! Our goal is
$350,000 and 2000 donors. We are confident that with your help we can hit our
Why do we have a donor goal? In order to keep our status as a
501(c)3 non-profit entity in the United States we must show that
we are supported by the "general public." This requirement exists
to prevent non-profits from becoming "front companies" controlled
by a few persons or corporations looking to take advantage of the
benefits bestowed on a charity. Our non-profit status aside, our
donor count is a reflection of the strength of the FreeBSD community.
Having a large and supportive donor base will place the FreeBSD
Foundation in a stronger position to meet the needs of the FreeBSD
Why do we need to raise so much money? First, take a look
at all the projects we are funding this year. We
have funded or approved eight projects.
project development budget is $100,000 and we plan on funding more this year.
This year we have received more requests for BSD-related conference sponsorships.
And, we're seeing a significant increase in people wanting to attend conferences,
but needing assistance.
How have we spent the money so far this year?
Sponsored FreeBSD related conferences like BSDCan,
AsiaBSDCon, MeetBSD Poland, MeetBSD
California, KyivBSD, NYCBSDCon, and the BSD Toolchain Summit.
Provided 13 travel grants and funding to individuals to attend these
and other conferences this year.
Provided grants for projects that improve FreeBSD, like Resource Containers,
BSNMP Improvements, Userland DTrace, High Available Storage,
Flattened Device Tree, FreeBSD jail based virtualization,
DAHDI FreeBSD driver port, and Closed Captioning for FreeBSD Technical Videos.
Provided legal assistance for the Project.
Provided equipment for developers working to improve FreeBSD and
projects like the DAHDI FreeBSD driver port project. We purchased servers
and parts for computer repairs for the Project. We also paid for shipping of equipment to various
Please consider making a donation to the foundation. You can do
this by going to
http://www.freebsdfoundation.org/donate/. And if you sign up for a
subscription, you can wistfully ignore our future pleas for donations,
knowing you've already done your part!
Project development is an integral part of our mission. Back in February we
solicited for proposals. We were pleased to receive so many
interesting proposals. It's not always easy deciding which ones
we should accept. Besides spending the time to review each proposal,
we have to determine how this will impact the OS. Is this an
improvement or added support that we have received many requests
for? Is it a larger project that will use up more of our budget?
What percentage of users will benefit? And, sometimes we have to
bring in experts to help us understand the importance of the project.
We have eight projects that we are currently funding or have recently
completed. We asked
the project developers to write short summaries of their projects
to help us publicize what they are doing. Sit back and take a moment
to catch up on our latest projects that are helping to improve
I am very happy to confirm the completion of development activities which
brought the Flattened Device Tree (FDT) support for FreeBSD.
The FDT technology is primarily applicable for embedded systems, and allows to
describe computer hardware resources in a uniform and extensible way,
independent of CPU architecture or underlying firmware. This hardware
description covers information like address space (ranges) assignments,
multi-purpose pins usage, interrupts routing and so on, and is maintained
completely outside of the kernel. The FDT idea is inherited from Open Firmware
IEEE 1275 device-tree notion, and it has been deployed by the embedded
Direct benefits for embedded FreeBSD will be encouraging code reuse (FDT
infrastructure is common and shared), easier porting to new systems and
multi-platform kernels (a single kernel image able to run on many similar
platforms) and others.
We currently have 2 PowerPC-based platforms and 6 ARM-based, which are able to
fully run off a device tree configuration. This shows that while this project
functionality is self contained, it should be considered an important but only
initial step for FDT adoption, and other embedded FreeBSD platforms have to be
converted to a new convention.
Merging of the code with HEAD is in progress at the moment, and because the
project scope involves modifications in several important aspects of the
FreeBSD system (loader, kernel, userspace tools), the integration process
requires particular attention (and time) in order to make it seamless and
avoid any regressions.
I would like to thank The FreeBSD Foundation for sponsoring this
development and Warner Losh, who kindly agreed to be the technical reviewer
for the project. Special thanks go also to Lukasz Wojcik (Semihalf) for all
the great work on this project. Thank you guys!
DTrace is a general purpose and lightweight tracing framework that
allows administrators, developers and users to investigate causes of
system failure or performance bottlenecks. The FreeBSD operating system
has had support for kernel-only DTrace since FreeBSD 8.0, but DTrace
userland support was missing. Having userland support in DTrace allows
inspection of userland software itself and its correlation with the
kernel, thus allowing a much better picture of what exactly is going on
behind the scenes.
This project will first concentrate on adding libproc support for symbol
to address mapping, address to symbol mapping, breakpoint setup and the
rtld interactions with DTrace. Next it will focus on DTrace process
control, importing the pid provider and adapting it to FreeBSD and
porting the userland statically defined probe provider (usdt). Finally
it will bring in the plockstat provider.
"By having userland DTrace support, companies can make their
products perform much better on FreeBSD due to the fact that they now
have access to this amazing tool," said FreeBSD developer Rui Paulo.
He also said, "When we mix the userland support with the kernel side
DTrace support, we can also make FreeBSD a better operating system because
we can investigate performance bottlenecks much easier."
The project should be completed by September 2010.
FreeBSD has been well known for its jail based virtualization during the last decade.
With the import of the virtual network stack, FreeBSD's operating system level
virtualization has reached a new level.
This project includes cleanup of two years of import work and development and, more
notably, brings the infrastructure for a network stack teardown. Cleanly shutting
down a network stack in FreeBSD will be the major challenge in the virtualization area
to get the new feature to production ready quality for the 9.x release lifecycle.
Further, the project includes generalization of the virtual network stack framework,
factoring out common code. This will provide an infrastructure and will ease virtualization
of further subsystems like SYSV/Posix IPC with minimal overhead. All further virtualized
subsystems will immediately benefit from shared debugging facilities, an essential feature
for early adopters of the new technology.
"Improved jail based virtualization support, that continues to be very lightweight and as
easily manageable as classic jails, will be a killer feature for the next few years," said
Bjoern A. Zeeb, FreeBSD developer. He also added, "It will allow people to partition their
FreeBSD server, run simulations without racks of hardware, or provide thousands of virtual
instances in hosting environments fairly easy and efficiently. While this follows the trend
of green computing, it also adds to FreeBSD's virtualization portfolio with Xen or other more
heavyweight hypervisor support, which can be mixed with jails as needed."
While work in this area will have to continue, the funding for this project will end mid-July 2010.
Edward Tomasz Napierala has been awarded a grant to implement resource
containers and a simple per-jail resource limits mechanism.
Unlike Solaris zones, the current implementation of FreeBSD Jails does not
provide per-jail resource limits. As a result, users are often forced to
replace jails with other virtualization mechanisms. The goal of this project
is to create a single, unified framework for controlling resource utilization,
and to use that framework to implement per-jail resource limits. In the future,
the same framework might be used to implement more sophisticated resource controls,
such as Hierarchical Resource Limits, or to implement mechanisms similar to AIX WLM.
It could also be used to provide precise resource usage accounting for administrative
or billing purposes.
"It's great that the Foundation decided to fund this project," Edward noted.
"It will make jail-based virtualization a much better choice in many scenarios,
for example for Virtual Private Server providers."
I'm very happy to report to FreeBSD users that the HAST project I was
working on for the last three months is ready for testing and already
committed to the HEAD branch.
I'll describe what HAST does in few words. HAST allows for synchronous
block-level replication of any storage media (called GEOM providers,
using FreeBSD nomenclature) over a TCP/IP network for fast failure
recovery. HAST provides storage using the GEOM infrastructure, meaning
it is file system and application independent and can be combined with
any existing GEOM class. In case of a primary node failure, the cluster
will automatically switch to the secondary node, check and mount the
UFS file system or import the ZFS pool, and continue to work without
missing a single bit of data.
I must admit the project was quite challenging, not only from the technical
point of view, but also because it was sponsored by the FreeBSD Foundation.
The FreeBSD Foundation has a great reputation and is known to select the
projects it funds very carefully. I felt strong pressure that should I fail,
the FreeBSD Foundation's reputation might be hurt. Of course, not a single
dollar would be spent on a failed project, but the FreeBSD community's
expectations were very high and I really wanted to do a good job.
During the work a number of people contacted me privately offering help,
explaining how important HAST is for FreeBSD and giving me the motivation to soldier on.
I hope that HAST will meet the community's expectations and I myself am looking forward to using it.
Once again, I'd like to thank the HAST sponsors: the FreeBSD Foundation, OMCnet Internet Service GmbH, and TransIP BV.
This project includes several enhancements to the existing FreeBSD
SNMP framework, including SNMPv3-compliant user authentication, packet
encryption and view-based access control. In addition, the project
also includes a new module that will allow full SNMP management and
monitoring of the FreeBSD wireless networking stack. When the
project is completed, FreeBSD should be the OS of choice when building
open source-based embedded wireless appliances due to the advanced
capabilities of its wireless network stack, and the light-weight,
secure and complete management solution that bsnmpd(1) will provide
out of the box. Existing FreeBSD installations that use bsnmpd(1) for
monitoring will also benefit from the added security and finer-grained
access-control to SNMP data.
"SNMP is the defacto standard for network monitoring," said Shteryana
Shopova, FreeBSD developer. She also added, "SNMP is used
everywhere - in network servers, switches, routers, firewalls,
workstations, ip phones, printers, UPSs, all sorts of embedded
appliances. I am happy to have the opportunity to work on several
additions to bsnmpd(1) that have been requested by the FreeBSD
Max Khon has been awarded a grant to finish the DAHDI FreeBSD driver port.
The purpose of DAHDI/FreeBSD project is to make it possible to use
FreeBSD as a base system for software PBX solutions.
DAHDI (Digium/Asterisk Hardware Device Interface) is an open-source
device driver framework and a set of HW drivers for E1/T1, ISDN digital
and FXO/FXS analog cards. Asterisk is one of the most popular open-source
software PBX solutions.
The project includes porting DAHDI framework and HW drivers for E1/T1,
FXO/FXS analog and ISDN digital cards to FreeBSD. This also includes
TDMoE support, software and HW echo cancellation (Octasic, VPMADT032)
and HW transcoding support (TC400B). The work is ongoing in the official
DAHDI SVN repository with the close collaboration with DAHDI folks at
The project is nearing its completion: DAHDI framework and HW drivers
telephony cards has been ported and tested. There are a number of success
stories from early adopters who use E1/T1 and FXO/FXS cards on FreeBSD for several months.
A pilot project to improve the machine
generated captions of technical conference lectures from the
YouTube channel has been completed. The 73 videos in this channel
have been viewed over 200,000 times since the channel
launched in late 2008, and the addition of human-edited
transcripts to some of our most popular videos makes this content more
accessible to people around the world.
In addition to the benefits to the hearing impaired, captions are very
useful for international viewers as well as for the improved
discoverability of this content by search engines. The improved
quality of the English language transcripts also improves the quality
of the automated
translation of the captions into over 45 different languages. It
is also now possible to search for words and phrases in the audio
transcripts and get a link directly to videos that contain spoken
content of that word or phrase.
For example, try searching for a
line from one of Dr. Kirk
McKusick's FreeBSD Kernel Internal Lectures. The above link will
take you to the Google Video Search Result page where one of Dr.
McKusick's lectures containing the phrase as long as dinosaurs and
mainframes is the first result, along with a snippet of the
transcript from his lecture, just as you would see the snippet from
text content on a web page. A dozen of our most popular videos of
FreeBSD technical content are now captioned and fully indexed allowing
users to search for very technical terms and get access to lecture
material from BSD Conferences.
The ports management team is very grateful to the FreeBSD Foundation
for sponsoring two new head nodes for the ports building cluster,
provided by iXsystems at cost. The ports building cluster, informally
known as pointyhat, is used for a variety of tasks, most importantly
regression testing of a number of subsystems and building ready to install
binary packages for the release ISO images and downloadable from the ftp mirror sites.
Each of the new head nodes has a larger capacity, both with regard to performance
but also in amount of space available for the staging areas, allowing for faster,
and thus more, build cycles. Additionally, having two head nodes will allow us to
dedicate one of them for building production-ready binary packages, adding predictability
for our users to when what types of packages are available for installation, and dedicate
the other for regression testing of large port updates, ports infrastructure improvements,
the cluster scheduling code, and FreeBSD itself. The latter is especially useful as the
cluster is a heavy user of almost all subsystems, from CPU, memory, disk I/O, and ZFS,
to networking and NFS.
Over the last few weeks, Mark Linimon has been working hard to get the first of
the two new nodes online and has already produced its first package. This has involved
a substantial rework of our custom codebase. We are looking forward to getting both of
the nodes in full production and using the new possibilities they will provide.
AsiaBSDCon is a technical conference on *BSD operating systems and
opensource software in Asian countries. AsiaBSDCon 2010, the 5th in
the conference series, was held March 2010, in Tokyo, Japan.
This year we had 22 talks including tutorials and regular paper
sessions. Twelve of the talks were ones that covered FreeBSD-related
topics such as new kernel features in the latest release,
bleeding-edge development topics, and community updates. Proceedings,
photos, and videos can be found at the official web site.
The FreeBSD Foundation has been one of our primary sponsors for years, and
the sponsorship is essential to continue AsiaBSDCon. Conference
venue, food, printed proceedings, airfare for invited speakers;
running a conference is money-consuming. It greatly helps us keep the
registration fee affordable unlike typical international conferences
The conference is quite international and inter-project; a good
mixture of FreeBSD, NetBSD, and OpenBSD people from Europe, North
America and Asia attended. It is also the place Japanese FreeBSD
developers get together once a year. Over 40 active FreeBSD
developers attended in the last year, and face-to-face interchange and
brainstorming among people from different countries, different
projects are helping development activities of the FreeBSD Project in
The program committee is now planning and working on
Official Web Site: http://asiabsdcon.org/
BSDCan is a conference for people using and working on BSD-related projects,
such as DragonflyBSD, FreeBSD, NetBSD, and OpenBSD. We have always put
emphasis upon developing relationships within and between projects.
BSDCan 2010 was our 7th conference. As has become the custom, a FreeBSD
developer summit was held in the two days before the conference. Record
numbers attended the Dev Summit which carried over into the conference proper.
It was great to see representatives from so many more companies. I saw many
great ideas take root and the start of cooperation on several projects.
These new relationships will no doubt lead to improvements in FreeBSD.
The talks during the Dev Summit are beginning to attract a wider audience,
and we've been talking about opening this up to the general audience by
creating a fourth track at BSDCan 2011.
As impossible as it sounds, each year has seen an increase in the quality
of talks and the number of proposals submitted.
Our single biggest cost is travel and accommodation. Without sponsorship,
we would not be able to bring in speakers from overseas.
The FreeBSD Core Team and The FreeBSD Foundation held a summit on BSD
licensed toolchains at BSDCan 2010. Our goal was to foster candid
discussion of a way forward for the FreeBSD toolchain in conjunction
with other projects and commercial users of FreeBSD. We aimed for a
diverse set of opinions while keeping attendance small to facilitate
The major decisions of the summit were:
To push forward with the import of the clang C/C++ compiler for
inclusion in FreeBSD 9.0 with the intent of eventually replacing GCC
in the base system. Since the summit, clang has been committed to
HEAD. This effort has been lead by Roman Divacky and Ed Schouten.
Adding easy to use support of external toolchains. This is necessary
on embedded platforms which may require technologies not available in
a current branch and will generally allow us to support architectures
not supported by our base compiler.
The agenda of the toolchain summit may be viewed at:
The meetBSD 2010 Conference was a great opportunity to present new
ideas to the community, meet some of the developers and in general
to gather all BSD fans in one place, promote discussions and information
exchange. The two day conference (July 2-3) took place at the
Jagiellonian University in Krakow which is the oldest university in
Poland (established in 1364) and one of the oldest universities in Europe.
This year's meetBSD was again organized to bring together community
representatives, system developers, users and fans of BSD systems and to
stimulate the discussion on present and future problems. All that we were
trying to achieve throughout a series of technical presentations, that
continued also outside the conference (during the social event for example).
The higher goal of the conference was to find new ways of collaboration,
new ideas and tools used in addressing problems appearing within the BSD
OS area. Not only was it a strictly technical meeting - we did everything
so that it looked and felt professional, attractive for commercial vendors
and open source community. We do believe that creating a strong conference
brand like meetBSD will bring more people from the FreeBSD community together.
There are several interesting subjects and issues that definitely demand public
attention, and to name a few: raising public awareness on the use of open software,
the BSDA certification, creating university based BSD student groups and bringing
BSD to more developers and IT companies.
The conference gathered over 130 people. Speakers from 9 countries did 13
presentations (mostly related to FreeBSD). That would not be possible without
support coming from our sponsors and patrons. Thanks to the FreeBSD Foundation
we were able to invite several highly qualified FreeBSD speakers and hire a
professional film crew, so that the conference could be videotaped and released
to the community (all videos will be available on the meetBSD web page soon).
All these high quality videos should be treated as our contribution and a big
"thank you" to the FreeBSD Foundation.
To spice things up a bit we are going to leak some of the feedback
that we received from this year's conference survey:
"This year's meetBSD was definitely worth visiting. Wide range of
presentations that were interesting not only for complete BSD magicians,
well organization and surprises that I did not see on other events of this
type. It was the place to meet BSD developers and people doing really serious
work in the Open Source area. Either at the venue or in a pub with beer
in your hand ;)" - Michał Dobroczyński, attendee from Copenhagen, Denmark.
"The meetBSD of 2010 was the best opportunity to experience the BSD community
in Central Europe. Splendid choice of place and smooth organization made this
event a nice refinement over previous BSD and other IT conferences in our country.
It's good to see that we are not falling behind the Linux crowd." - Sławek Żak, a meetBSD speaker.
These words are definitely heart warming and assure us, that this was the best BSD event
organized in central Europe. All conference materials are available on http://meetbsd.org.
Do not forget to check out photo and video sections. Once again, thank you for your
support and feedback - all your opinions and thoughts are very important for us and
will be used to organize an even better meetBSD 2011 Conference.
Every year we sponsor FreeBSD related conferences, projects, and
developer travel. We believe that BSD-centered and FreeBSD-specific
conferences play critical roles in expanding the FreeBSD user
community and supporting collaborative development. Our grants may
be for something as little as performance software to large projects
like Network Stack Virtualization.
When a friend and I started our technology business 11 years ago in 1997, we didn't
choose FreeBSD, it chose us. But we're sure glad it did, and we came to build our company on FreeBSD.
As a small website design and web application development firm, we didn't intend to get into the
web hosting business. We started hearing from our clients that they would appreciate being able
to host their site through the same provider that built it for them, and so we decided to try offering
that service as a convenience. The local Internet service provider that we were sharing office space
with had a FreeBSD 2.1 box with space on it, so we get our username and password, and we were up and running.
When we got big enough to need our own server for site hosting, we didn't spend too much time looking
around at the options. The consensus at the time (1998 now) was that Linux, FreeBSD and NetBSD were
all basically the same, and that it was mostly a matter of preference and what kind of commercial support
was available to help you through any rough patches (though the license wars certainly raged on even then).
With our friends at the ISP sitting just on the other side of the bookshelves, we knew we had some of the
best FreeBSD product support we could hope for.
In 2000, our business model had largely shifted into building database driven website applications, and
the expectations for what features came with a web hosting service had expanded significantly. We were
no longer just providing web hosting with Apache on FreeBSD - we knew we needed to support an
expanding reliance on the PostgreSQL and MySQL database systems, the qmail and vpopmail e-mail
systems and other dedicated services. We started building new servers as dedicated single function boxes,
and in each case, it was a no-brainer to install FreeBSD. Our use of the ports system to turn it into just the
kind of box we needed saved us lots of time along the way. As we've transitioned into more "mainstream"
hosting platforms like our use of cPanel, FreeBSD is still powering it behind the scenes.
You may not necessarily need to hear that FreeBSD is a reliable platform for running Internet services.
But I think it's important to remember that software like FreeBSD is affecting the way that people live
their lives every day, whether it's supporting businesses like ours, enabling hobbyists just getting into
open source software, or any of the thousands of other "real world" roles it plays.
For much of the world, choice of operating system is an arbitrary decision to make.
We believe that for us, it's made all the difference in building a successful business.