Diesen Namen gab die Computer Systems Research Group (CSRG) der The University of California at Berkeley den Verbesserungen und Änderungen an AT&Ts 32V UNIX®. FreeBSD beruht auf der Arbeit der CSRG.

Die Beobachtung, dass viele Leute Meinungen zu unkomplizierten Themen äußern, während gleichzeitig über ein kompliziertes Thema gar nicht oder nur wenig diskutiert wird. Die Herkunft des Ausdrucks wird in den FAQ erläutert.

Siehe: Berkeley Software Distribution

Der Name für einen wechselseitigen Ausschluss (mutual exclusion), der einen großen Teil der Kernel-Ressourcen schützt. Zu Zeiten als auf einer Maschine nur ein paar Prozesse liefen und die Maschine nur eine Netzwerkkarte und insbesondere nur einen Prozessor besaß, war dieser einfache Mechanismus zum Verriegeln (lock) einer Ressource völlig ausreichend. Heutzutage entstehen durch den wechselseitigen Ausschluss Geschwindigkeitsengpässe. Die FreeBSD-Entwickler arbeiten daran, Giant durch Locks zu ersetzten, die einzelne Ressourcen schützen. Auf Einprozessor- und Mehrprozessor-Maschinen können dadurch mehr Prozesse parallel ausgeführt werden.

Threads, die im Kernel laufen. Näheres entnehmen Sie der Home-Page des Projekts.

Siehe: Kernel Scheduler Entities

Der FreeBSD-Kernel benutzt eine Reihe von Ressource-Locks, um den Zugriff auf Ressourcen zu regeln. In FreeBSD-CURRENT-Kerneln (nicht in Release-Kerneln) befindet sich das Diagnose-System witness(4), das Verklemmungen (deadlock) zur Laufzeit erkennt. witness(4) ist vorsichtig: daher gibt es schon mal Falschmeldungen aus. Eine richtig erkannte Verklemmung bedeutet soviel wie “Wenn Sie Pech gehabt hätten, wäre es jetzt zu einer Verklemmung gekommen”.

Richtig erkannte Verklemmungen (LOR) werden schnell behoben. Prüfen Sie daher http://lists.FreeBSD.org/mailman/listinfo/freebsd-current und die Seite LORs Seen bevor Sie die Mailinglisten kontaktieren.

Siehe: Lock Order Reversal

Das Einbringen von Funktionen oder Fehlerbehebungen aus dem -CURRENT-Zweig in einen anderen Zweig, meist -STABLE.

Normalerweise werden Änderungen an FreeBSD zuerst im -CURRENT-Zweig getestet und dann in den -STABLE-Zweig übernommen. Selten kommt es vor, dass eine Änderung zuerst im -STABLE-Zweig vorgenommen wird und anschließend im -CURRENT-Zweig übernommen wird.

Dieser Ausdruck wird auch benutzt, wenn eine Fehlerbehebung von -STABLE in einem der Sicherheitszweige übernommen wird.

Siehe auch: Merge From Current.

Siehe: Merge From Current

Siehe: Merge From Stable

Siehe: Project Evil

Zeigt an, dass eine gewünschte Änderung (aus einem Fehlerbericht oder einer Anforderung) überholt ist. Die Ursache können beispielsweise spätere Änderungen in FreeBSD, geänderte Netzwerk-Standards oder jetzt veraltete Hardware sein.

Siehe: Overtaken By Events

Ein Kopfschmuck, ähnlich den Eselsohren, der FreeBSD-Committern gereicht wird, wenn sie den Bau kaputtmachen, Revisionsnummern verkleinern oder sonstigen Schaden im Quellbaum anrichten. Jeder Committer, der etwas taugt, besitzt schnell eine stattliche Sammlung. Der Begriff wird (meist?) scherzhaft verwendet.

Prinzip der kleinsten Überraschung

Änderungen an FreeBSD sollten nach Möglichkeit vor dem Benutzer verborgen sein. Das willkürliche Umordnen der Variablen in /etc/defaults/rc.conf verletzt zum Beispiel dieses Prinzip. Entwickler beachten das Prinzip, wenn Sie über für Benutzer sichtbare Änderungen nachdenken.

Siehe: Principle Of Least Astonishment

Der Arbeitstitel des von Bill Paul geschriebenen NDISulator. Der Name bezieht sich darauf, dass es (philosophisch gesehen) schlimm ist, einen solchen Treiber überhaupt schreiben zu müssen. Der NDISulator ist ein Kompatibilitätsmodul, das es erlaubt, Microsoft Windows™ NDIS-Miniport-Netzwerktreiber mit FreeBSD/x86 zu benutzen. Für gewöhnlich ist dies die einzige Möglichkeit, Karten mit einem Treiber, dessen Quellen verschlossen sind, zu benutzen. Siehe src/sys/compat/ndis/subr_ndis.c.