Einige Anmerkungen haett ich noch...
a) Ports. Irgendwer meinte weiter oben vorkompiliert. Die vorkompilierten sind die Packages. Die Ports sind eine [geordnete] Ansammlung von Makefiles, Links, Patchanweisungen und Patchen fuer unterschiedlichste Programme. Wenn ein solcher Port dann installiert wird, werden die Sourcen aus dem Netz gezogen, entpackt, bei Bedarf gepatcht (meist wenn die Originalsourcen zu Linux-zentrisch geschrieben sind [selten]) und mit noetigen plattformspezifischen Parametern kompiliert und installiert.
Es ist aehnlich zu apt und emerge - fuer die die Ports ja auch Pate standen.
Die Packages sind das gleiche in rosa nur eben vorkompiliert und mit den ueblichen Einschraenkungen (man kann keine Compileroptionen angeben etc, sollte klar sein).
Es gibt nicht fuer jeden Port Packages, es wird allerdings angestrebt.
Wobei gesagt werden muss das *BSD viel Source basierter arbeiten, daher erklaert es sich das es im Unterschied zum apt System fuer die *BSDs kein binaeres Systemupdate gibt - wobei hier allerdings zZ Bestrebungen laufen.
b) BSD = BSD. Die Sache mit SuSe, Debian etc kommt schon recht nahe, allerdings verwenden diese dann doch immer die gleichen Sourcen und patchen diese bis zur Unkenntlichkeit. Aber ausgehend alles aus einem Tree. Aufgrund der Patches ist es meist schlecht einen RedHat Kernel auf eine SuSe pressen zu wollen, aber mit dem Vanilla Kernel laufen sie alle. So etwas ist innerhalb der BSDs nicht moeglich.
Sie stammen alle (mehr oder minder direkt) von 4.4BSD(-Lite2) ab und haben alle die BSD-Philosophie (im Prinzip die Lizenz *g*) gemein. Ansonsten sind es unabhaengige Codebaeume auch wenn Features natuerlich regelmaessig abgeglichen werden.
NetBSD: -- Ziel moeglichst sauberer Code um einfach viele Plattformen zu unterstuetzen (Toaster)
OpenBSD: -- Security ueber Performance. Die Frage ist nicht was ein Sicherheitsloch ist sondern was eines werden koennte.
FreeBSD: -- Usability und Performance, egal ob Server, Laptop oder Desktop. Schwerpunkt IA32 und Alpha (aber nicht nur)
DragonFlyBSD: fork der freeBSD 4 Linie die demnaechst nicht mehr aktiv weiterentwickelt wird. Im Hinterkopf behalten, Fruehjahr 2004 koennte heiss werden.
c) Security. Wie jedes *nix legen die BSDs auf Sicherheit viel Wert. Das kommt einfach daher das Unixe schon immer Mehrbenutzersysteme mit Netzanbindung waren. Die laengste Zeit beim stopfen von Sicherheitsloechern braucht meist das neukompilieren der ueberarbeiteten Sourcen selbst. Zur Gruendlichkeit beim Beheben dieser Luecken sei gesagt das man nach wie vor immer mal wieder noch in Security-Announcements Updates im 3.x und sogar 2.x Branch sieht [freeBSD]. Bei anderen verhaelt es sich aehnlich.
Es sind kleine Feinheiten die diesen Ruf vmtl begruenden. [Nachfolgend freeBSD] Das faengt an bei so Tools wie `sockstat` (wie `lsof -i`) die von Haus aus dabei sind, geht ueber ICMP Bandwith Limiter zu den sysctls ueber die man wirklich quasi alles im TCP Stack und System allgemein manipulieren kann (RFC1323, drop Syn/Fin, Random IP ID, Blackhole, log_in_vain, Stealth, Buffergroessen sowieso um mal ein bisschen was zu nennen), die kernel securemodes mit denen man auch root das Leben zur Hoelle machen kann
bis hin zu den jails (advanced chroot) die iirc noch immer nicht erfolgreich und komplett nach Linux portiert wurden. ACLs sind seit neuestem auch dabei.
Alles kleine Dinge mit denen man das System sicher machen _kann_ und zwar so, das der Angreifer sollte er dann mal doch im System drin sein verwundert feststellt das seine Probleme gerade erst anfangen. Man kann es allerdings auch offen wie ein Scheunentor betreiben. Is klar.
Als mehrjaehrigem Debian Nutzer werd ich dir das nicht sagen muessen, aber ich machs trotzdem. Sicherheit ist weder ein Produkt noch ist es kaeuflich. Nach der Installation eines BSD gehts dir deshalb noch lange nicht gut. Die BSDs bieten aber eben eine Fuelle von Moeglichkeiten und maechtigen Tools die bei
richtiger Verwendung und
Pflege deine Situation verbessern koennen.
Durch die zentrale Entwicklung des gesamten OS von einem [grossen] Team ist es hier naheliegenderweise besser moeglich alle Aspekte des OS soweit menschlich moeglich abzudecken und zu koordinieren.
Zu den Staerken des Systems evtl noch:
-- IPv6 Ready wie kein anderes System. Ich kenne einige ueberzeugte Linuxer die ihr v6 Gateway auf *BSD umgestellt haben
-- *ng (Next Generation). Obgleich der Ruf der BSDs ja etwas konservativ ist ist die Entwicklung ungebremst, wobei hier jedes BSD wieder in "seiner" Sparte aktiv ist. Auf free findet man an der Lanzenspitze Dinge wie GEOM, SMPng (`SMP-Beast`) oder den SCHED_ULE (true SMP Scheduler), bei net maechtige und saubere Systemframeworks und open beschert uns Dinge wie W^X, pf oder auch openSSH.
-- komplettes System "aus einem Guss"
-- kein Dateisystemwildwuchs
-- die Dokumentation
Zu dem was grunix anmerkte mit fefe's Benchmark noch ein Wort: der 2.6er Linux Kernel war wenn ich mich recht erinnere in nahezu allen Breichen aehnlich gut oder besser. Gewisse Feinheiten (pre-alloc bei 4000+ etc) mal aussen vor.
Diese Feinheiten in Kombination mit dem Scheduler fuehren aber zu dem beschriebenen Last Symptom. Die *BSDs sind noch responsive bei Lasten bei denen man den meisten Linux Systemen bereits einen Livelock attestieren kann.
Is jetzt doch laenger geworden als ich vor hatte, ich hoffe ihr habt schoen durchgehalten, zur Belohnung duerft ihr euch jetzt nen Keks holen.
das System offen wie