From: Christian Weisgerber (naddy_at_mips.rhein-neckar.de)
Date: 03. Aug 1999
Thimo Neubauer <tneubaue_at_ix.urz.uni-heidelberg.de> wrote:
> Solaris ist das aeltere Un*x von Sun (entspricht wohl einem BSD),
> SunOS das neuere.
Uih. Eine Tabelle fasst die etwas verwirrende Situation am besten
zusammen:
uname | Produkt | Basis | im Jargon
----------+-------------+--------+-----------
SunOS 4.1 | Solaris 1 | 4.3BSD | "SunOS"
SunOS 5.x | Solaris 2.x | SVR4 | "Solaris"
Wobei zuletzt Solaris 2.7 (SunOS 5.7) zu "Solaris 7" mutiert ist.
So schön ist Marketing.
> Wenn man Linux kennt, dann wird einem SunOS ziemlich
> bekannt vorkommen, da kommen wohl viele der Ideen von Linux her.
Zumindest habe ich mich damals, mit etwas SunOS-Hintergrund, auf Linux
sofort wohlgefühlt - ganz im Gegensatz zu Solaris. Lag wohl daran, dass
die unter Linux eingesetzte GNU-Welt sich weitgehend an BSD orientiert
hat.
> Mit den diversen BSDs konsultierst Du am besten eine der immer wieder
> in c't oder iX gedruckten Tabellen der Un*x-Verwandtschaften...
<URL:ftp://ftp.de.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/
misc/bsd-family-tree>
> Der groesste Unterschied zu Linux ist, dass der Netzwerkstack speziell von
> NetBSD schneller und robuster ist
Was zu beweisen wäre.
> (der Server mit dem regelmaessig groessten Netzaufkommen der
> Welt, ftp.cdrom.com, ist ein NetBSD-System)
Das würde David Greenman aber überraschen. Seine ftp.cdrom.com ist
natürlich eine dicke FreeBSD-Kiste. Die Büchse schaufelt täglich ein
Terabyte oder so raus, Tendenz steigend.
> und dass Kernel und Software in einem grossen Sourcenbaum haengen.
> So kann man mit "make world" unter BSD die neusten Versionen aller
> Programme ziehen, kompilieren und installieren kann.
Das ist allerdings eine feine Sache.
Zuerst einmal gibt es bei BSD, wie bei den traditionellen kommerziellen
Unices, eine klare Abtrennung zwischen dem eigentlichen Lieferumfang
des Systems und Software von Drittanbietern. Bei Linux-Distributionen
ist das eher verschwommen.
Bei {Free,Net,Open}BSD ist das ganze System, Kernel wie Userland,
in *einem* CVS-Baum vorhanden, der öffentlich lesbar (und für
Entwickler schreibbar) ist. Damit ist die komplette Revisionsgeschichte
seit 4.4BSD abrufbar. Ich halte bei mir eine Kopie des FreeBSD-CVS-
Repositories vorrätig (z.Zt. ~660MB inkl. ports-all und doc-all)
und kann daraus nicht nur komplett oder auszugsweise den Source
des aktuellen FreeBSD 3.2-STABLE (stabiler Zweig) oder 4.0-CURRENT
(Entwicklerzweig) ausbuchen, sondern z.B. auch den eines antiken
FreeBSD 2.0, so ich das jemals wollte.
Bei BSD fühlt man sich für alles, was im CVS-Baum ist, *zuständig*.
Es wird zwar auch zum Teil Software von Dritten integriert (z.B.
sendmail, gcc), aber man scheut sich nicht, daran lokale Modifikationen
vorzunehmen, und Verantwortung wird nicht auf einen Upstream-Maintainer
abgeschoben.
Das ganze System ist konsistent und kann in einem Durchlauf, dem
berühmten "make world", komplett neu übersetzt werden. Das vermeidet
die bei Linux-Distributionen so beliebten Probleme, das ganze System
einheitlich aktuell und konsistent zu halten, und solche Peinlichkeiten
wie Source-RPMs, die sich auf dem System, von dem sie eigentlich
Bestandteil sein sollen, nicht bauen lassen.
Was Software von Drittanbietern angeht, so gibt es dafür die Ports/
Packages-Sammlung. Die hat bei FreeBSD z.Zt. einen Umfang von 2500+
Paketen. Ein "Port" ist ein Gerüst aus einem Makefile, ggfs. einigen
Patches, und ein paar Hilfsdateien. Man fügt den Distributions-Tarball
des Programs hinzu (kann auch automatisch per FTP/HTTP geholt
werden), und ein "make install" packt das aus, fügt die Patches
mit *BSD-spezifischen Anpassungen hinzu, baut das ganze durch,
installiert es, und trägt es in eine einfache Paketverwaltungsdatenbank
ein. Die Details sind ganz anders, aber vom Prinzip entspricht die
Erstellung eines Ports der eines Source-RPMs. Das ganze gibts auch
vorcompiliert, so dass es zur Installation nur noch ausgepackte
werden muss, heisst dann "Package". (Terminologie-Falle: NetBSD
bezeichnet abweichend einen Port als "package" und ein Package als
"pre-compiled package".)
-- Christian "naddy" Weisgerber naddy_at_mips.rhein-neckar.de
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET