---
title: Chapter 1. Introduction
authors:
  - author: Murray Stokely
  - author: Jeroen Ruigrok van der Werven
prev: books/developers-handbook/parti
next: books/developers-handbook/tools
---

[[introduction]]
= Introduction
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:
:skip-front-matter:
:xrefstyle: basic
:relfileprefix: ../
:outfilesuffix:
:sectnumoffset: 1

include::shared/mirrors.adoc[]
include::shared/authors.adoc[]
include::shared/releases.adoc[]
include::shared/en/mailing-lists.adoc[]
include::shared/en/teams.adoc[]
include::shared/en/urls.adoc[]

toc::[]

[[introduction-devel]]
== Developing on FreeBSD

So here we are. System all installed and you are ready to start programming. But where to start? What does FreeBSD provide? What can it do for me, as a programmer?

These are some questions which this chapter tries to answer. Of course, programming has different levels of proficiency like any other trade. For some it is a hobby, for others it is their profession. The information in this chapter might be aimed toward the beginning programmer; indeed, it could serve useful for the programmer unfamiliar with the FreeBSD platform.

[[introduction-bsdvision]]
== The BSD Vision

To produce the best UNIX(R) like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability.

[[introduction-archguide]]
== Architectural Guidelines

Our ideology can be described by the following guidelines

* Do not add new functionality unless an implementor cannot complete a real application without it.
* It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
* The only thing worse than generalizing from one example is generalizing from no examples at all.
* If a problem is not completely understood, it is probably best to provide no solution at all.
* If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution.
* Isolate complexity as much as possible.
* Provide mechanism, rather than policy. In particular, place user interface policy in the client's hands.

From Scheifler & Gettys: "X Window System"

[[introduction-layout]]
== The Layout of [.filename]#/usr/src#

The complete source code to FreeBSD is available from our public repository. The source code is normally installed in [.filename]#/usr/src# which contains the following subdirectories:

[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| Directory
| Description

|[.filename]#bin/#
|Source for files in [.filename]#/bin#

|[.filename]#cddl/#
|Utilities covered by the Common Development and Distribution License

|[.filename]#contrib/#
|Source for files from contributed software

|[.filename]#crypto/#
|Cryptographical sources

|[.filename]#etc/#
|Source for files in [.filename]#/etc#

|[.filename]#gnu/#
|Utilities covered by the GNU Public License

|[.filename]#include/#
|Source for files in [.filename]#/usr/include#

|[.filename]#kerberos5/#
|Source for Kerberos version 5

|[.filename]#lib/#
|Source for files in [.filename]#/usr/lib#

|[.filename]#libexec/#
|Source for files in [.filename]#/usr/libexec#

|[.filename]#release/#
|Files required to produce a FreeBSD release

|[.filename]#rescue/#
|Build system for the [.filename]#/rescue# utilities

|[.filename]#sbin/#
|Source for files in [.filename]#/sbin#

|[.filename]#secure/#
|Contributed cryptographic sources

|[.filename]#share/#
|Source for files in [.filename]#/usr/share#

|[.filename]#sys/#
|Kernel source files

|[.filename]#tests/#
|The FreeBSD test suite

|[.filename]#tools/#
|Tools used for maintenance and testing of FreeBSD

|[.filename]#usr.bin/#
|Source for files in [.filename]#/usr/bin#

|[.filename]#usr.sbin/#
|Source for files in [.filename]#/usr/sbin#
|===
