[linux-l] Welche Distribution ist die richtige?

[Peter Ross]

On Sat, 1 Jul 2006, Volker Grabsch wrote:

> Aber da ich schonmal einen BSD-Nutzer hier antreffe: Es gibt doch
> mehrere BSDs, richtig?

Ja. Und FreeBSD ist nicht unbedingt besser, jedes hat einen anderen 
Ansatz und ein etwas anders geartetes Ziel.

Es gibt derzeit mindestens 4 Abkoemmlinge von 4.4BSD. Als jemand, der 
aktiv nur FreeBSD einsetzt, bin ich vielleicht nicht die ultimative 
Quelle, ich versuchs trotzdem.

FreeBSD entstand aus 386BSD, dem Projekt, 4.4BSD auf PC-Hardware zu 
portieren. Daher ist es urspruenglich vorallem "Intel-PC-lastig", und 
angesichts der weiten Verbreitung von PC-Hardware ist es nicht 
verwunderlich, dass Du zunaechst von FreeBSD hoerst. Es gibt aber 
inzwischen eine Handvoll Ports auf andere Architekturen, z.B. auf 
SPARC-Rechner sowie Itanium und AMD64 sowie ARM.

Neben der "Hauptdistribution" gibt es Projekte wie FreeSBIE (eine Art 
FreeBSD-Knoppix), PC-BSD, eine Art FreeBSD-Distribiution fuer Desktops, 
PicoBSD fuer Minimalinstallationen fuer Kleinstgeraete etc.

NetBSD hatte dagegen von vornherein den Anspruch, moeglichst portabel zu 
sein. Du findest da wahrscheinlich was fuer so ziemlich alles jenseits des 
Abakus';-)

OpenBSD ist ein Projekt, welches ein besonderes Augenmerk auf Sicherheit 
legt. OpenSSH wird hier z.B. gepflegt.

Seit einiger Zeit gibt es DragonFlyBSD, entstanden aus FreeBSD 4, von 
Entwicklern, die bei der Weiterentwicklung etwas andere Ziele als die 
hatten, die in FreeBSD-5/6 verwirklicht wurden und werden.

Trotz unterschiedlicher Ansaetze (und manchmal auch persoenlicher 
Eitelkeiten) gibt es einen regen Austausch unter den einzelnen Projekten, 
Treiber werden von einem System aufs andere portiert, FreeBSD hat z.B. den 
bei OpenBSD entwickelten Paketfilter pf integriert etc.

Ausserdem "strahlt" natuerlich *BSD auf eine Menge kommerzielle 
Entwicklungen aus. Die BSD-Lizenz erlaubt es ja, den Code zu modifizieren 
und selbst einzusetzen, ohne die Aenderungen freilegen zu muessen. Daher 
ist es juristisch einfacher, ihn in existierende kommerzielle Systeme zu 
integrieren, oder komplett darauf aufbauende Systeme (z.B. Fileserver oder 
Firewalls) zu entwickeln, ohne den in-House entstandenen Mehrwert 
freigeben zu muessen.

So ist FreeBSD-Code in Mac OS X zu finden, und ein Haufen Appliances 
verwenden BSDs. Oft unbemerkt. Es ist schon eine Weile her, dass ich in 
einer australischen PC-Zeitschrift (APC) einen Vergleich von NAS-Servern 
fand, uberschrieben "Windows oder Linux?" Erst im Kleingedruckten der 
Tabelle konnte man sehen, dass von 6 sogenannten "Linux-Systemen" die 
Haelfte in Wirklichkeit FreeBSD-basiert waren.

Das scheint mir auch das Hauptproblem der *BSD-Systeme zu sein: die 
oeffentliche Wahrnehmung. Open Source und Linux werden in der 
Oeffentlichkeit ja schon synonym verwendet.

Wen Du unter den 15000 FreeBSD-Ports nachschaust, wirst du selten ein 
Paket vermissen, welches Du unter Linux verwendest.

Sollte es doch einmal der Fall sein (z.B. weil ein kommerzieller Anbieter 
nur Linux-Binaries bereitstellt), ist es moeglich, unter den BSDs 
Linux-Applikationen laufen zu lassen. Sie werden nicht etwa emuliert, der 
Kernel ist tatsaechlich in der Lage, Linux-System-Aufrufe zu beantworten, 
ist also sozusagen ein "Linux-Kernel". Das linux-base-Paket installiert so 
eine Handvoll Red-Hat-Libraries (glibc und Co.), auf denen 
Linux-Applikationen laufen koennen.

Wer sich laenger mit FreeBSD beschaeftigt, der weiss vorallem die Eleganz 
zu schaetzen. Der Grund liegt meines Erachtens hier:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/introduction-archguide.html

1.3 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.