Das freie Unix-Derivat FreeBSD – Maskottchen ist ein Teufel, genannt Daemon – hat mit Linux viele Gemeinsamkeiten. Bei Lizenz, Paketen, Dateisystemen und der zugrunde liegenden Philosophie ist aber damit Schluss. Warum das so ist, erklärt der Autor dieses Beitrags, ein erklärter BSD-Fan.

Linux ist nicht das einzige Open-Source-Betriebssystem: FreeBSD[1] und seine nahen Verwandten OpenBSD[2] und NetBSD[3] sind freie Abkömmlinge des 4.3er BSD und des 4.4er BSD Lite, die an der Universität von Berkeley entwickelt wurden (siehe Kasten “BSD-Geschichte”). Der folgende Artikel beleuchtet die Unterschiede zwischen Linux auf der einen Seite und FreeBSD auf der anderen.

BSD-Lizenz und GPL

Einen Teil seines Erfolgs verdankt Linux seiner Lizenz, der GPL[4]. Der Lizenz unterliegt von Haus aus die ganze GNU-Software, die ja einen erheblichen Teil jeder Linux-Distribution ausmacht: die GNU Compiler Collection, Make, Emacs, GNU Privacy Guard, die Bash sowie die GNU Binary Utils wie »tar«, »sed«, »awk« und »gzip«.

Die GPL verlangt, dass die Programmierer jede Änderung an GPL-Code ebenfalls dieser Lizenz unterstellen und der Öffentlichkeit zugänglich machen müssen. Im Gegenzug hat das GNU-Projekt Linux als Zielbetriebssystem angenommen – wohl auch, weil GNU Hurd sich nur sehr langsam entwickelt.

FreeBSD unterliegt einer eigenen freien Lizenz, die jedoch keinen solchen Zwang wie die GPL vorsieht: So müssen Änderungen nicht publik gemacht werden. Sie verlangt lediglich, das angegebene Copyright nicht zu entfernen[5]. Ein bekanntes Beispiel für nicht-öffentlichen Code, den die BSD-Lizenz zulässt, ist Mac OS X, das auf FreeBSD basiert und das Apple als proprietäre Software verkauft.

Aus einem Hause – aus einem Guss

Eine Linux-Distribution besteht bei weitem nicht nur aus dem namengebenden Kernel. Die vielen Tools und Programme, die das System komplettieren, fügt der jeweilige Distributionshersteller hinzu. Die Firma oder das Projekt bestimmen dabei (zumindest zum Teil) die Dateisystem-Hierarchie selbst – wo Konfigurationsdateien und Programme liegen und welche Dateisysteme verfügbar sind.

Trotz einiger nützlicher Projekte für die Vereinheitlichung der Linux-Distributionen gibt es nennenswerte Unterschiede: SuSE Linux zum Beispiel installiert große Programme wie Open Office nach »/opt«, während Debian »/opt« fremd ist. Das kann beim Installieren Distributions-fremder Software zu Problemen führen, die aber mit Symlinks und Ähnlichem zu kitten sind.

FreeBSD hingegen ist aus einem Guss, denn der Kernel und die C-Bibliothek sowie Systemkommandos, Compiler, aber auch Netzwerk-Services wie Sendmail, Kerberus und Bind kommen aus einer Hand und sind ideal auf das System eingestellt. Zusätzliche Software, die nicht vom FreeBSD-Kernteam stammt, wird über die Ports beziehungsweise Packages (siehe unten) installiert.

Kerneldesign

FreeBSD-Entwickler behaupten, dass ihr Code übersichtlicher und lesbarer gestaltet ist als der von Linux. Sie halten die Linux-Kernelquellen für Flickwerk, ganz zu schweigen von einer Vielzahl unflätiger Kommentare in ihnen: Man versuche mal ein »grep -R Schimpfwort . | less« im Linux-Kernelverzeichnis.

Das Design des FreeBSD-Kernels ist – wie bei anderen BSD-Kerneln und bei Linux – im Grunde monolithisch. Der erste Unix-Kernel war noch klein, erst das Hinzufügen von Netzwerk-Cache, Treibern und Dateisystemen hat ihn auf die heutige Größe gebracht. Das Wachstum führte zur Auslagerung nicht ständig benötigter Teile, die als Module zur Laufzeit gelinkt werden.

Das erleichtert auch die Arbeit der Treiber-Entwickler, die sonst bei jeder Änderung den Kernel neu übersetzen und das System booten müssten. Aktueller Trend bei der Entwicklung von Betriebssystemen ist es, die Kernelgröße durch Auslagern System-unkritischer Teile wie Dateisystem und Gerätetreiber in den Userspace zu verringern – man spricht dann von einem Microkernel.

Anders als bei Linux kommt in den FreeBSD-Kernel nur Code, der für Hardware-Unterstützung und Speichermanagement benötigt wird – einen HTTP-Server im Kernel gibt es unter FreeBSD nicht. Auch wenn das Einlagern anderer Teile eine höhere Geschwindigkeit bringt, im Sinne der Sicherheit ist das nicht. Dafür ist der Linux-Kernel in puncto Multiprozessor-Unterstützung und Threading der FreeBSD-Entwicklung voraus.

BSD-Geschichte

BSD, die Berkeley Standard Distribution, ist einer der bedeutendsten Entwicklungszweige der älteren Unix-Geschichte (siehe Abbildung 1). Aus ihm gingen einige wichtige Unix-Derivate wie Sun OS (Anfang der 80er) und Nextstep (Ende der 80er) hervor. Für Intel-Architektur optimiert FreeBSD entstand etwa zur selben Zeit wie Linux aus einer Portierung von 4.3 BSD für die 386-PCs. Das erklärt auch die Optimierung von FreeBSD auf die x86-Architektur. In letzter Zeit kümmern sich die Entwickler aber auch um Architekturen wie Alpha, Sparc 64 und PC 98. FreeBSD kann (im Unterschied zu Linux) auf die jahrzehntelange BSD-Erfahrung zurückgreifen, was bei Design-Entscheidungen im Einzelfall hilfreich ist. Stabil genug für Microsoft Aus demselben Grund gilt FreeBSD als ziemlich stabil, weshalb große Firmen wie Yahoo darauf vertrauen. Kurios: Bis vor kurzem lief Microsofts E-Mail-Service Hotmail auf FreeBSD-Servern – offenbar zufrieden stellend. Als die Redmonder dann auf hauseigene Software umstiegen, mussten sie einige Server hinzufügen, um eine vergleichbare Performance zu erreichen. Abbildung 1: Der sehr vereinfachte Entwicklungsbaum der Unix-Geschichte. BSD-Unixe, von denen mittelbar Ende 1992 FreeBSD abzweigt, machen einen wichtigen Teil davon aus.

Partitionen heißen Slices

BSD-Systeme bezeichnen Festplatten-Partitionen als Slices. Eine Partition dagegen entspricht in der FreeBSD-Terminologie einer logischen Partition in einer Slice. Im Gegensatz zu den meisten anderen Betriebssystemen unterscheidet FreeBSD nicht zwischen primären und erweiterten Partitionen.

Ein Unterschied besteht beim Umgang mit dem Swap-Bereich: Linux verwendet normalerweise eine spezielle Partition, BSD hingegen die normale BSD-Partition. FreeBSD kommt also mit einer einzigen Slice aus, Linux braucht zumindest zwei. Für Software-RAID gibt es unter FreeBSD übrigens ein eigenes, gut funktionierendes Projekt.[6]

Installation und Konfiguration

Die Installation von FreeBSD ist gut mit jener von Debian-Linux vergleichbar. Ein interaktives Textmenü namens Sysinstall führt durch die Installation (siehe Abbildung 4). Sysinstall verzichtet auf grafischen Schnickschnack, was auf den ersten Blick für Erstanwender spartanisch wirken mag. Doch führt es genauso zuverlässig wie beispielsweise Yast 2 durch die Installation. Als Installationsmedien taugen CD-ROMs, Tapes, DVDs oder (Boot-)Disketten. Zusätzliche Software ist via NFS, FTP oder HTTP ladbar.<@99 L_Dreieck (E)>E

Nach dem Aufsetzen des Systems kann der Administrator stets zum Installationsprogramm zurückkehren, um Systemeinstellungen wie Konsole, Zeitzone, Netzwerk, XFree86-Server oder Fdisk menügesteuert durchzuführen. Das ist vor allem für Umsteiger und nicht so erfahrene Benutzer sehr hilfreich. Momentan ist die Entwicklung an einer grafischen Version des FreeBSD-Installers im Gange.

Kernel konfigurieren und Quellen aktuell halten

Während die Linux-Welt menügesteuerte Tools (»menuconfig« & Co.) verwendet, um den Kernel zu konfigurieren, kommt für die gleiche Aufgabe bei FreeBSD ein Konfigurationsfile zum Zuge. Dieser Ansatz wirkt zwar archaisch, er bietet aber auch Vorteile: Wer ein Modul zum Kernel hinzufügen möchte, muss sich nicht lange durch Menüs hangeln, sondern fügt einfach das Modul in die Konfigurationsdatei ein – und fertig.

FreeBSD verwendet CVSup, um die Sourcen (System und Userland) und die Ports aktuell zu halten. Der Admin erstellt ein so genanntes Supfile, das den entfernten Mirror und den Releasezweig spezifiziert. CVSup vergleicht den Server mit dem lokalen Repository und gleicht die Unterschiede über Deltas aus. Das Versionsmanagement braucht also nur die eigentlichen Änderungen Bandbreite-schonend zu übertragen.

Das erleichtert auch das Updaten von einer Version auf die andere. Der gesamte Source von FreeBSD ist zirka 400 MByte groß, ein installiertes Grundsystem umfasst dagegen etwa 250 MByte. Für die Standardfälle unnötige Software installiert FreeBSD nicht automatisch. Weitere Programme finden über das Portssystem ihren Weg auf den Rechner.

Software über das Portssystem einspielen

Der klassische Weg, Software von Dritten auf einem Unix-System zu installieren, ist: Sourcecode oder die Binaries runterladen, mit Tar oder GZip entpacken, die Dokumentation studieren, falls nötig das Makefile anpassen und den Sourcecode kompilieren, das Programm installieren und schließlich testen. Bei FreeBSD kommt stattdessen das Portssystem ins Spiel, eine Sammlung von zurzeit 9000 Ports, die diese Schritte automatisieren[7].

Konkret handelt es sich um in Kategorien organisierte Verzeichnisse. Diese so genannten Portskeletons repräsentieren die Programme. In jedem Verzeichnis liegt ein Makefile, das den Programmnamen, die Version, den Ort, von dem es runterzuladen ist, sowie Abhängigkeiten zu anderen Ports benennt. Die Datei »pkg-plist« listet die Verzeichnisse und Dateien, die bei der Installation dem System hinzugefügt werden, was später eine saubere Deinstallation ermöglicht. Darüber hinaus umfasst ein Portskeleton eine Datei mit MD5-Prüfsumme, einen Kommentar zum Programm und gegebenenfalls Patches.

Einfache Anweisungen steuern die Installation und Deinstallation eines Programms: Führt der Admin »make install clean« im Verzeichnis eines Ports aus, überprüft FreeBSD zunächst, ob das Distfile, also der Tarball mit dem Sourcecode, im Verzeichnis vorhanden ist. Wenn nicht, wird er heruntergeladen. Danach wird die Prüfsumme verglichen, dann der Sourcecode entpackt. Sind Patches vorhanden, kommen auch sie zur Anwendung.

Ist die Zielsoftware beispielsweise auf eine Bibliothek angewiesen, prüft das Portssystem Vorhandensein und Version dieser Bibliothek und installiert sie bei Bedarf nach. Sind die Abhängigkeiten erfüllt, wird das Makefile erstellt, die Software kompiliert und installiert. Jetzt überflüssige, beim Übersetzen entstandene Dateien gehen den Weg alles Irdischen. Anschließend wird das Programm inklusive der Abhängigkeiten in die Datenbank »pkgdb« eingetragen, sodass die Dateien beim Starten immer richtig linken. Das Listing 1 zeigt beispielhaft und in aller Ausführlichkeit eine Kette solcher Ereignisse.

Packages als Alternative

FreeBSD kennt zur Software-Installation einen zweiten Ansatz: Jedes über die Ports installierbare Programm ist auch als Package verfügbar. Das sind kompilierte Ports, die der Admin mit den PKG-Tools ins System installiert. Ein Package ist zumeist kleiner als der Tarball seines Sourcecodes und muss nicht mehr kompiliert werden. Bei umfangreichen Programmsammlungen wie KDE oder Gnome bringt das Vorteile.

Andererseits: Packages sind in aller Regel sehr konservativ kompiliert, damit sie auf möglichst vielen Systemen laufen, was auf dem eigenen System vielleicht Performance und Ressourcen kostet. Andere, meist modulare Programme wie der Apache-Server variieren zudem ihre Funktionalität je nach dem eingestellten Übersetzungs-Setup, was Packages kaum ausnutzen können.

Abbildung 2: Die Slices (Partitionen) eines typischen FreeBSD-Systems.

Abbildung 3: Zum Vergleich: So sähe das System in der Linux-Version aus.

Sourcen sind meist besser

Hinzu kommt, dass die Lizenzierungsvorschriften mancher Software das Ausliefern als Binary verbieten. Manche Leute misstrauen Binaries, denn Sourcen kann man, was allerdings Wissen voraussetzt, auf Sicherheit überprüfen. Um Patches anzuwenden, sind die Quellen naturgemäß sowieso erforderlich. Die meisten Gründe sprechen also für das Installieren über die Ports, aber der Anwender hat immer die freie Wahl. Egal ob Ports, Packages oder Sourcecode: FreeBSD erkennt und berücksichtigt manuell installierte Libraries und Programme, was für das Paketmanagement vieler Linux-Distributionen nicht selbstverständlich ist.

Apropos Linux-Distributionen: Gentoo Linux[8] hat mit seinem so genannten Portage-System Anleihen beim Portssystem von FreeBSD genommen[9]. Gentoo versuchte dabei, aus den Erfahrungen von FreeBSD zu lernen, und implementierte Verbesserungen. Während die FreeBSD-Ports auf »sh« und »make« basieren, verwendet Gentoo Python – in puncto Portabilität sicherlich ein Vorteil. Darüber hinaus ist Gentoo besser beim Optimieren auf die CPU. Das mag zum Teil daran liegen, dass Linux mehr Architekturen unterstützt und die meiste FreeBSD-Software auf x86-Architektur geschrieben wird. In Sachen Geschwindigkeit liegen jedoch die FreeBSD-Ports vorne, vor allem beim Auflösen von Abhängigkeiten.

Aktuelle Software

FreeBSD ist immer gut mit aktueller Software bestückt. Der Autor dieses Beitrags kennt keine Linux-Distribution, die ihre Pakete vergleichbar aktuell hält. Während Debian beispielsweise für das Umstellen auf KDE 3 einigen Wochen benötigte, war dies bei FreeBSD nach ein paar Stunden geschehen.

Mitte April dieses Jahres war für Debian Sid und für FreeBSD die in Tabelle 1 genannte Software aktuell. Wer sich auch ohne installiertes FreeBSD einen Überblick über die aktuell verfügbaren Programme verschaffen will, kann auf Freshports.org[10] den ganzen Portstree browsen.

Linux-Software ist mehrheitlich lauffähig

Ein Großteil der Linux-Sourcen lässt sich ohne große Änderungen in und für FreeBSD kompilieren. Treten größere Inkompatibilitäten auf, kümmern sich die Port-Maintainer darum.

Die Lage der Anwender verbessert außerdem, dass viele native Linux-Binaries in der Linux-Emulation von FreeBSD ohne erheblichen Geschwindigkeitsverlust laufen. Auf diese Weise kommt der FreeBSD-Anwender in den Genuss von kommerziellen Programmen wie der Oracle-Datenbank, denn Applikationen dieser Klasse sind für FreeBSD nativ absehbar nicht erhältlich.

Filesystem-Cache und Journaling

Das Linux-Standarddateisystem Ext 2 verwendet so genannte asynchrone Metadaten-Updates, um Änderungen am Dateisystem auf die Festplatte zu übertragen. Dank des zwischengeschalteten Buffer-Cache werden die Updates der Metadaten zwischen Updates normaler Daten geschoben und das System muss nicht mehr auf jedes Update warten. Operationen, die zahlreiche Metadaten ändern, laufen daher schneller.

Im Störungsfall ist jedoch die Konsistenz nicht gesichert: Kommt es zu einem Ausfall während einer umfangreichen Operation, kann es passieren, dass das Dateisystem in einem unbestimmten Zustand verbleibt. Es lässt sich nicht mehr eindeutig bestimmen, welche Daten schon auf den Datenträger geschrieben sind und welche noch fehlen. Die Datenblöcke einer Datei könnten schon auf der Platte stehen, während die Inode-Tabelle noch nicht aktualisiert ist.

Ein auf diese Weise beschädigtes Dateisystem ist mindestens einem aufwändigen Filesystem-Check zu unterziehen – oder es bleibt im schlimmsten Fall irreparabel und muss neu erzeugt und mit Backup-Daten gefüllt werden.

“Dirty region logging” heißt das Zauberwort, mit dem man dieses Dilemma umgeht – auch bekannt (bei Linux: ReiserFs und Ext 3) als Journaling. Hier werden die Metadaten-Updates zunächst synchron in einen kleinen Plattenbereich geschrieben, der Logging Area, und von dort aus asynchron auf die vorgesehen Bereiche gesichert. Der Vorteil liegt auf der Hand: Da die Logging Area ein kleines und zusammenhängendes Stück Speicher ist, legen die Festplattenköpfe auch kleinere Wege zurück, was Zeit spart im Vergleich zu den klassischen synchronen Updates.

Nachteil dieser Methode: Die Daten werden zweimal in den Speicher geschrieben – bei regulärer Arbeit (keine häufigen Metaoperationen) wird das Dateisystem langsamer. Das nehmen Journaling-Filesysteme aber angesichts der verbesserten Ausfallsicherheit in Kauf. Im Falle eines Zusammenbruchs angefangener Operationen führt das Dateisystem entweder zu Ende oder verwirft sie ganz einfach komplett.

Abbildung 4: Ein interaktives Textmenü namens Sysinstall führt durch die FreeBSD-Installation.

Softupdates von UFS vereinen die Vorteile

UFS 2, das Standarddateisystem von FreeBSD 5.0 (siehe Kasten “Neuerungen in FreeBSD 5.0”) verfolgt einen anderen Lösungsansatz – Softupdates: Es hält die notwendigen Updates der Metadaten im Speicher und sortiert dann die auf Platte geschriebenen. Bei starken Metadatenänderungen passiert es, dass nachfolgende Operationen, ältere Operationen desselben Elements im Speicher einholen können, wenn es noch nicht auf die Platte geschrieben ist.

Nach einem Absturz werden alle Operationen, die noch nicht den Weg auf die Platte gefunden haben, rückabgewickelt. Das stellt den konsistenten Zustand von 30 bis 60 Sekunden zuvor sicher. Der verwendete Algorithmus garantiert, dass alle tatsächlich benutzten Ressourcen in den entsprechenden Block- und Inode-Tabellen als belegt markiert sind.

Der einzige Fehler, der auftreten kann, ist, dass Ressourcen noch als belegt markiert, aber von der Logik her bereits frei sind. Das Systemwerkzeug »fsck« erkennt und korrigiert diesen Zustand. Dass die Ressourcen irrtümlich belegt sind, ist derart unkritisch, dass man »fsck« auf eine elegante Art anwenden darf: als Background-Fsck. Dazu wird beim Starten des Systems lediglich ein Schnappschuss des Filesystems gemacht, mit dem »fsck« dann später in (relativer) Ruhe arbeitet.

Der große Vorteil besteht darin, dass die Dateisysteme gewissermaßen unsauber mittels »mount -f« eingebunden werden dürfen – die primären Dateisystem-Checks entfallen und das Betriebssystem geht sofort in den Multiuser-Modus. Der richtige »fsck« wird dann zur Laufzeit des Systems nachgeholt.

Anfangs vielleicht gewöhnungsbedürftig ist folgendes prinzipbedingte Verhalten: Nach einem Absturz und dem »fsck« entspricht der Datenzustand dem etwa 30 bis 60 Sekunden vor dem Crash – beispielsweise ist statt einer bereits angelegten, aber leeren Datei wie bei einem ungesicherten Dateisystem mit Softupdates die entsprechende Datei nicht mehr zu sehen. Das ist kein Wunder, denn weder die Metadaten noch der Datei-Inhalt wurden je auf die Platte geschrieben.

Eine andere Eigenheit ist, dass der nach einem »rm -r« eigentlich entstehende Platz nicht sofort verfügbar ist, sondern erst, sobald das Softupdate auch auf die Platte vermittelt ist. Das bereitet immer dann Probleme, wenn große Datenmengen in einem relativ kleinen Dateisystem zu ersetzen sind[11].

Dass FreeBSD sich mit UFS 2 für Softupdates entschieden hat, liegt an dem zentralen Vorteil dieses Prinzips, dass die Metadatenoperationen beinahe so schnell ablaufen wie in einem asynchronen Dateisystem und viel schneller als bei Logging-Filesystemen, die ja die Metadaten immer zweimal schreiben müssen. Der guten Performance stehen als Nachteil ein hoher Speicherbedarf und die (Fehler provozierende) hohe Komplexität des Codes gegenüber.

Philosophie-Unterschiede

Der größte sichtbare Unterschied zwischen Linux und FreeBSD offenbart sich in der Philosophie, nach der die Betriebssysteme entstehen: Während Linux-Entwickler recht zügig neue Features und Treiber einbauen, haben ihre FreeBSD-Kollegen eine konservative Einstellung zu diesem Thema. Ausnahme: Eine brandneue Technologie betrifft Netzwerk und Sicherheit.

Die Entwickler testen neuen Code lieber ausgiebig oder warten, bis die betreffenden Projekte die ersten Fehler beseitigen. Für den Desktopbereich ist das oft ein Nachteil, da dort die Benutzer die aktuellen Treiber und neuesten Features am schnellsten vermissen. Aber im Serverraum zählen ausgereifte und zuverlässige Systeme mehr als die Unterstützung einer schnellen Grafikkarte.

Fazit: Ruhig mal ausprobieren

Mit seiner schlanken, am ehesten mit Debian vergleichbaren Standardinstallation beschränkt sich FreeBSD auf das Wesentliche. Das verringert die Wahrscheinlichkeit von Sicherheitslücken – denn je mehr Services laufen, desto eher macht sich ein Sicherheitsloch auch bemerkbar. Außerdem findet der Admin nach dem Aufsetzen ein aufgeräumtes System vor, das er nach seinen Vorstellungen anpassen darf.

Die für FreeBSD angebotene Software ist meist sehr aktuell, viele Linux-Programme sind entweder schnell übersetzbar oder laufen recht performant als Binary in der Linux-Emulation. Dazu werden Teile des Linux-Kernels sowie wichtige Linux-Libraries installiert.

Der flächendeckende Siegeszug von Linux war und ist unstreitig – die Zahlen der Marktforschungsinstitute belegen es. Und die Linux-Gemeinde wächst weiter. FreeBSD erfüllt bei allen hier beschriebenen Unterschieden lizenzrechtlich und technisch vergleichbare Voraussetzungen wie Linux – warum es also nicht mal ausprobieren? (jk)

01 root@daemon:/home/shammer/verschiedenes/ports/wmdrawer>make install clean
02 >> wmdrawer-0.9.15.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
03 >> Attempting to fetch from http://people.easter-eggs.org/~valos/wmdrawer/.
04 Receiving wmdrawer-0.9.15.tar.gz (36404 bytes): 100%
05 36404 bytes transferred in 0.7 seconds (48.97 kBps)
06 >> daemon.xpm doesn't seem to exist in /usr/ports/distfiles/.
07 >> Attempting to fetch from http://www.daemon.li/downloads/.
08 Receiving daemon.xpm (23890 bytes): 100%
09 23890 bytes transferred in 0.5 seconds (45.58 kBps)
10 ===>  Extracting for wmdrawer-0.9.15
11 >> Checksum OK for wmdrawer-0.9.15.tar.gz.
12 >> Checksum OK for daemon.xpm.
13 ===>  Patching for wmdrawer-0.9.15
14 ===>  Applying FreeBSD patches for wmdrawer-0.9.15
15 /usr/bin/sed -i.bak -e "s,PREFIX =,#PREFIX =," /usr/home/shammer/verschiedenes/ports/wmdrawer/work/wmdrawer-0.9.15/Makefile
16 /usr/bin/sed -i.bak -e "s,-O2,," /usr/home/shammer/verschiedenes/ports/wmdrawer/work/wmdrawer-0.9.15/Makefile
17 ===>   wmdrawer-0.9.15 depends on executable: gmake - found
18 ===>  Configuring for wmdrawer-0.9.15
19 ===>  Building for wmdrawer-0.9.15
20 gcc -Wall `gdk-pixbuf-config --cflags` -DUSE_GDKPIXBUF -c config.c
21 gcc -Wall `gdk-pixbuf-config --cflags` -DUSE_GDKPIXBUF -c images.c
22 gcc -Wall `gdk-pixbuf-config --cflags` -DUSE_GDKPIXBUF -c wmdrawer.c
23 wmdrawer.c: In function `xNextEventOrTimeout':
24 wmdrawer.c:580: warning: implicit declaration of function `bzero'
25 gcc `gdk-pixbuf-config --libs` -lgdk_pixbuf_xlib -o wmdrawer config.o images.o wmdrawer.o
26 strip wmdrawer
27 ===>  Installing for wmdrawer-0.9.15
28 install -c -s -o root -g wheel -m 555 /usr/home/shammer/verschiedenes/ports/wmdrawer/work/wmdrawer-0.9.15/wmdrawer /usr/local/bin
29 install -c -o root -g wheel -m 444 /usr/home/shammer/verschiedenes/ports/wmdrawer/work/wmdrawer-0.9.15/doc/wmdrawer.1x.gz /usr/local/man/man1/wmdrawer.1x
30 ===>   Generating temporary packing list
31 /bin/mkdir -p /usr/local/share/pixmaps
32 /bin/mkdir -p /usr/local/share/examples/wmdrawer
33 install -c -o root -g wheel -m 444 /usr/home/shammer/verschiedenes/ports/wmdrawer/work/wmdrawer-0.9.15/wmdrawerrc.example /usr/local/share/examples/wmdrawer/wmdrawerrc.example
34 install -c -o root -g wheel -m 444 /usr/ports/distfiles/daemon.xpm /usr/local/share/pixmaps/
35 
36 Sample configuration file has been copied to
37 /usr/local/share/doc/wmdrawer/
38 please copy it to your homedir as .wmdrawerrc
39 and adjust it to your needs!
40 
41 ===>   Compressing manual pages for wmdrawer-0.9.15
42 ===>   Registering installation for wmdrawer-0.9.15
43 ===>  Cleaning for libiconv-1.8_2
44 ===>  Cleaning for gettext-0.11.5_1
45 ===>  Cleaning for gmake-3.80
46 ===>  Cleaning for libtool-1.3.4_4
47 ===>  Cleaning for expat-1.95.6_1
48 ===>  Cleaning for wmdrawer-0.9.15