1.4 Linux und BSD: Unterschiede und Gemeinsamkeiten
Aus der teilweise gemeinsamen Geschichte ergeben sich für Linux und BSD viele Gemeinsamkeiten, und entsprechend sind Unterschiede oft erst bei genauerer Betrachtung erkennbar. Eine wichtige Gemeinsamkeit besteht darin, dass es sich bei Linux wie bei den bestehenden BSD-Derivaten um quelloffene Software (engl. open source) handelt.
1.4.1 Freie Software
GNU/Linux
Dass Linux selbst eigentlich nur den Kernel umfasst, wurde bereits angesprochen. Die für den Betrieb nötige Systemsoftware kommt in erster Linie vom bereits erwähnten GNU-Projekt (http://www.gnu.org). Diese Initiative gibt es seit 1984 und damit viel länger als Linux selbst. Das Ziel war von Anfang an, ein völlig freies Unix zu entwickeln, und mit Linux hatte das Projekt seinen ersten freien Kernel. Somit ist auch die Bezeichnung GNU/Linux für das Betriebssystem als Ganzes gebräuchlich.
Was aber ist eigentlich freie Software? Wenn man ein Programm schreibt, so besitzt man an dessen Quelltext ein Urheberrecht wie ein Buchautor. Die resultierende Software kann verkauft werden, indem man dem Käufer durch eine Lizenz gewisse Nutzungsrechte einräumt. Alternativ kann man aber auch festlegen, dass das eigene Programm von anderen kostenlos benutzt werden kann. Gibt man sogar den eigenen Quellcode frei, so spricht man von offener Software.
Im Linux- und BSD-Umfeld gibt es nun unterschiedliche Lizenzen, die mit teilweise besonderen Bestimmungen ihr jeweils ganz eigenes Verständnis von »Freiheit« verdeutlichen.
Die GPL
Copyleft
Linux steht wie alle GNU-Projekte unter der GNU Public License, der GPL. Laut dieser Lizenz muss der Quellcode eines Programms frei zugänglich sein. Das bedeutet jedoch nicht, dass GPL-Software nicht verkauft werden darf. [Fn. Mehr dazu finden Sie unter www.gnu.org/philosophy/selling.de.html.]
Selbst bei kommerziellen Distributionen zahlt man allerdings oft nicht für die Software selbst, sondern für die Zusammenstellung der Software, das Brennen der CDs/DVDs, die eventuell vorhandenen Handbücher und den Installationssupport.
Die GPL stellt damit Programme unter das sogenannte Copyleft: Verändert man ein entsprechendes Softwareprojekt, so muss das veränderte Ergebnis wieder frei sein. Man darf zwar Geld für ein GPL-basiertes Produkt nehmen, muss aber den Sourcecode samt den eigenen Änderungen weiterhin frei zugänglich halten.
Somit bleibt jede einmal unter die GPL gestellte Software immer frei – es sei denn, alle jemals an einem Projekt beteiligten Entwickler stimmen einer Lizenzänderung zu. Bei großen Softwareprojekten wie dem Linux-Kernel mit vielen Tausend Beteiligten ist das undenkbar.
Die BSD-Lizenz
Im Unterschied zu der im Linux-Umfeld verbreiteten GPL verzichtet die von BSD-Systemen verwendete Lizenz auf ein Copyleft. Man darf zwar den ursprünglichen Copyright-Vermerk nicht entfernen, doch darf entsprechend lizenzierte Software durchaus Ausgangspunkt für proprietäre, kommerzielle Software sein. Die BSD-Lizenz ist also weniger streng als die GPL, aber aufgrund der möglichen freien Verteilbarkeit und Veränderbarkeit immer noch freie Software.
Weitere freie Projekte
Mehr Lizenzen
Natürlich gibt es freie Software nicht nur vom GNU-Projekt oder von den BSD-Entwicklern. Jeder kann für eigene Softwareprojekte die GPL oder die BSD-Lizenz verwenden. Natürlich kann man – wie beispielsweise das Apache-Projekt – auch eigene Open-Source-Lizenzen mit besonderen Bestimmungen entwickeln. Jedoch haben bekannte Lizenzen den Vorteil, dass sie in der Community auch anerkannt sind und einen guten Ruf genießen oder – wie die GPL – sogar bereits von einem deutschen Gericht in ihrer Wirksamkeit bestätigt wurden.
1.4.2 Ports und Packages
Verteilung der Software
Einen weiteren Unterschied zwischen Linux und der BSD-Welt ist die Art, wie Software jeweils verpackt und vertrieben wird. Man unterscheidet hierbei zwischen den unter Linux-Distributionen verbreiteten Paketen und den BSD-typischen Ports.
Port
Ein Software-Port enthält Anweisungen, um eine Software aus dem Quellcode zu übersetzen und automatisch zu installieren. Ein Software-Package hingegen ist ein kompilierter Port. Das bedeutet, dass die Software bereits in binärer Form vorliegt und zum Installieren nur noch entpackt und an die richtige Stelle im System kopiert werden muss.
Ein Software-Port kann in der Regel bei der Kompilierung besser an das System angepasst werden, diese benötigt jedoch zusätzliche Zeit. Ein Software-Package benötigt die Kompilierungszeit nicht, ist aber unter Umständen weniger optimal an den Prozessor angepasst. Zu gegebener Zeit werden wir ausführlich auf die BSD-Ports und unterschiedliche Systeme zum Paketmanagement unter Linux eingehen.
1.4.3 Versionierung
Linux-Versionen
Vor allem mit der Versionierung unter Linux gibt es einige Verständnisprobleme. Der Linux-Kernel erschien bis vor einigen Jahren in zwei Versionskategorien: einer Entwickler- und einer Stable-Version. Die Entwicklerversionen hatten ungerade Zahlen als zweite Versionsnummern (2.1, 2.5), die Stable-Versionen hingegen gerade Zahlen (2.0, 2.2, 2.4, 2.6). [Fn. Sollten Sie einmal jemanden treffen, der Ihnen von irgendwelchen komischen Versionsnummern à la Linux 14.0 erzählen will, so bringt der Betreffende offensichtlich die Nummerierungen der Distributionen und die des Kernels durcheinander.] Eine dritte Zahl nummerierte die unterschiedlichen kleineren Releases, die beispielsweise mit neuen Features ausgestattet waren.
Mittlerweile werden die Entwicklerversionen nicht mehr mit ungeraden Versionsnummern bezeichnet. Vor jeder neuen Version werden stattdessen einzelne Vorveröffentlichungen durchgeführt. Diese Vorveröffentlichungen (engl. Release Candidates) können anschließend durch die Community heruntergeladen und getestet werden. Werden Fehler gefunden, fließen deren Korrekturen in die nächste stabile Version ein.
Seit Kernel 2.6.11 kann zur schnellen Bereinigung schwerer Fehler auch eine vierte Versionsnummer geführt werden. Eine Version 2.6.21.1 umfasst gegenüber der Version 2.6.21 mindestens eine Verbesserung (in der Regel aber mehrere). Werden erneut Fehler gefunden, so wird eine weitere Version (2.6.21.2) herausgegeben. Werden auch in dieser Fehler gefunden, so setzt sich die Nummerierung auf diese Weise fort.
Eine Entwicklerversion enthält immer die neuesten Spielereien der Entwickler. Wenn Sie diese nicht wirklich brauchen oder nicht wissen, was Ihnen eine neue Version überhaupt bringt, lassen Sie besser die Finger davon und bleiben Sie bei der Stable-Version.
Der Grund dafür ist, dass die Stable-Versionen ganz einfach ausgereifter sind und mit großer Sicherheit stabil laufen. Entwicklerversionen können zwar durchaus auch sehr stabil laufen, müssen es jedoch nicht.
Aber keine Angst, aktuelle Distributionen beinhalten natürlich immer die Stable-Version. Sofern Sie nach diesem Buch immer noch Lust auf Linux haben und sich für die Innereien des Kernels interessieren, empfehlen wir Ihnen »Understanding the Linux Kernel, 2nd Edition« [BovetMacro02A] und das »Linux Kernel-Handbuch« [Love05A].
1.4.4 Maskottchen
Das Wichtigste dürfen wir natürlich auch nicht unterschlagen: die Maskottchen. Diese Identifikationsmerkmale werden Ihnen regelmäßig begegnen – nicht nur in der Netzwelt, sondern auch in diesem Buch, sobald es um Eigenarten der entsprechenden Systeme geht.
Das Linux-Maskottchen
Da Linus Torvalds ein Liebhaber von Pinguinen ist, wollte er einen als Logo für Linux haben. Ein Pinguin wurde dann von Larry Ewing mit dem gimp-Grafikprogramm erstellt. Die Figur gefiel Torvalds und fertig war Tux. Übrigens wurde das Linux-Logo für die Kernel der Version 2.6.29.x in einen Tasmanischen Teufel abgeändert. Die temporäre Logo-Änderung sollte darauf hinweisen, dass die Beutelteufel vom Aussterben bedroht sind.
Abbildung 1.1 Tux
Tux steht übrigens für Torvalds Unix. Und immer, wenn wir auf besondere Eigenheiten von Linux eingehen, die sich nicht (oder nur sehr bedingt) auf BSD oder Unix übertragen lassen, werden Sie am Seitenrand einen kleinen Pinguin bemerken.
Die BSD-Maskottchen
Anfang November 2005 erhielt auch FreeBSD ein neues Logo. Das neue NetBSD- Logo ist auch noch nicht alt. BSD allgemein (und bis vor Kurzem auch FreeBSD) hat eigentlich den BSD-Daemon mit Namen »Beastie« als Maskottchen – wie schon bei BSDi. Wenn wir von (Free)BSD sprechen, sehen Sie in diesem Buch das Icon mit dem Teufelchen am Seitenrand.
Sprechen wir hingegen speziell von OpenBSD, erscheint dieses Icon am Seitenrand. Es stellt »Puffy«, den Blowfish, dar. Blowfish ist zum einen ein von Bruce Schneier entwickelter kryptografischer Algorithmus und zum anderen eben ein kugeliger Fisch mit Stacheln. Die Stacheln des Blowfishs stehen für Sicherheit, das Primärziel des Open-BSD-Projekts.
Weitere Symbole in diesem Buch
[»]Dieses Icon steht für einen Hinweis.
[+]Dieses Logo kennzeichnet dagegen einen Tipp für die Praxis.
[zB]Mit diesem Icon werden Beispiele gekennzeichnet – schließlich kann man die meisten Sachverhalte am besten anhand eines kleinen Beispiels nachvollziehen.
Eine Glaubensfrage
Nach dem Linux-Hype folgte über einige Jahre ein BSD-Hype. In den letzten Jahren haben sich beide Trends stabilisiert. Zwischenzeitlich waren jedoch viele Benutzer (hauptsächlich testweise) von Linux zu BSD gewechselt. Warum das so war, ist nur sehr schwierig zu beantworten, da die Unterschiede im Leistungsumfang von Linux und BSD nur in wenigen Fällen von Bedeutung scheinen.
Generell lässt sich sagen, dass sich normalerweise weder ein Wechsel von Linux zu BSD noch ein Wechsel von BSD zu Linux als sonderlich lohnend erweisen wird, sofern man ihn nicht gerade wegen eines bestimmten Features vollzieht.
Linux uncool?
Wenn man die Communities etwas genauer betrachtet, fällt einem vielleicht auf, dass es zahlreiche Diskussionen darüber gibt, welches System das bessere sei und ob man nun eher der GPLv2 oder der BSD-Lizenz seine Opfergaben darbringen sollte. Wenn man ehrlich ist, sind viele solcher Diskussionen substanzlos und erscheinen als eine Art Religionskrieg. Wenn man noch etwas genauer hinschaut, scheint es auch oft um das Statussymbol Betriebssystem zu gehen und darum, sich vom Nicht-mehr-Hacker-OS Linux abzuheben, das nun so viele (Ex-)Windows-Anhänger verwenden.
Glücklicherweise gibt es aber auch einen Vorzug dieser Situation: Man lernt voneinander. Linux-Kernel, Linux-Distributionen und BSD-Derivate übernehmen bereits seit vielen Jahren Features voneinander beziehungsweise von anderen Systemen aus dem Unix-Umfeld – man denke nur einmal an die SVR4-IPC. Auch erwähnenswert ist das SVR4-Runlevel-System, das Linux übernommen hat, oder Kommandos wie pkill und pgrep, die BSD und Linux von Solaris übernahmen. Auf all diese Querverbindungen möchten wir in diesem Buch mit unserem Bezug auf BSD eingehen.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
