[linux-l] linux betriebssystem

[Peter Ross]

On Fri, 19 Aug 2005, Katja Saeger wrote:
> Am Dienstag, 16. August 2005 02:19 schrieb Peter Ross:
> > Hi Katja,
> > wie verlief Dein PCBSD (www.pcbsd.org) Abenteuer? Kommt schliesslich auch
> > mit KDE;-)
> Hi Peter,
> sei bitte nicht enttaeuscht, aber ich habe mich erstmal fuer Debian
> entschieden, laeuft auch schon auf dem Notebook und PC.

Als FreeBSD-Avocado (gruen, nicht braun) natuerlichst schwer
enttaeuscht;-)

> BSD werde ich auch noch installieren, aber erst in ein paar Monaten, wenn ich
> bei Debian besser durchsehe.

Na dann viel Spass! Auch erst einmal mit Debian. Eigentlich schade, dass
die beiden "grossen" kommerziellen Distributionen (Red Hat und SuSE) nicht
das Debian-Paketmanagement benutzen... Fuer mich das Debian-Highlight.

> Auch muss ich noch klaeren welches BSD: Open-, Free-, PC-, Net-.
> Oder gibt es noch mehr?

Ja, Dragonfly BSD;-)

Wenn es um den Kernel und eng daran liegende Software (libc etc.) geht,
dann sind aus 4.4BSD mindestens 4 Varianten entstanden:

zunaechst FreeBSD aus dem 386BSD von Steve Jolitz & Co., zunaechst
gedacht, um BSD auf den PC zu bringen,

(BTW: Die Anfang der 90er Jahre im Unix-Magazin und dann in der iX
veroeffentlichte Serie mit Beitraegen von Steve Jolitz, wie 4.4BSD auf den
386 portiert wurde, ueber Bootstrapping, Crosscompiling etc., war sehr
sehr lehrreich - ich wuenschte, ich koennte das heute nochmal lesen),

dann NetBSD, was eher den Ansatz hatte, auf moeglichst vielen Plattformen
zuhause zu sein,

dann das daraus hervorgegangene OpenBSD, welches versucht, mit besonders
grosser Sicherheit zu glaenzen,

und als neuester mir bekannter Entwicklung Dragonfly BSD, entstanden aus
FreeBSD 4, welches versucht, Probleme von FreeBSD 4, betreffend SMP,
Threading, Storage Layer etc. auf eine andere Art und Weise zu loesen als
es beim Sprung zu FreeBSD 5 realisiert wurde.

Einen wesentlichen Unterschied zu Linux sehe ich darin, dass *BSDs aus
einem Forschungsprojekt an der Berkeley University hervorgegangen sind,
und von daher auch schon eine gewisse "Ethik" geerbt haben, mal grob
gesagt: "Nutze, was Du hast, mache alles so einfach wie moeglich, sei
innovativ, arbeite durchdacht, lieber einmal richtig als dreimal gehackt."

Um auf die Probleme von FreeBSD-5 zurueckzukommen, eines der Probleme war,
dass dort einige Dinge wirklich neudesignt wurden (nach gruendlicher
Abwaegung, wieviel Aenderung realistisch ist, und was gewagt werden kann -
da es dort keinen ganz grossen Konsens gab, gibt's jetzt Dragonfly BSD) ,
was z.B. erst einmal die Performance zurueckwarf. Wobei das nicht ganz
objektiv ist - u.a.  merke ich bei meinem letzten
FreeBSD-7-Current-Snapshot auf dem Laptop einen irren
Geschwindigkeitsunterschied, ob ich das mit oder ohne Debug-Konfig baue -
nur macht Debugging bei -Current auch Sinn, schliesslich will man ja dort
das Neueste vom Neuesten testen und im Problemfall auch Fehler beseitigen
koennen.

FreeBSD-5 hatte ein bisschen ein Henne-Ei-Problem - es gab nicht soviele,
die es testeten, so dass man es nie wirklich als "Stable" bezeichnen
konnte, aber dadurch, dass es nicht als "Stable" galt, haben sich auch
zuwenige getraut..

Darum haben die FreeBSD-Entwickler beschlossen, ihren
Schiffbauererfahrungen zu vertrauen und das Schiff auch ohne TUeV ins
Wasser zu lassen. Well, zum Anfang war's schon noch ein bisschen wacklig,
inzwischen kann man sagen, dass viele Loecher gestopft sind und das Schiff
schon ordentlich in den Wellen liegt.

PC-BSD, worauf Du mich erst gestossen hast, basiert auf FreeBSD und nutzt
dessen Kernel und Grundsystem, und ist so etwas wie eine
"FreeBSD-Distribution", um eine Installation fuer Desktop-Nutzer einfacher
zu machen (traditionell kuemmerte sich die BSD-Gemeinde zunaechst darum,
robuste Server zu bauen, denn um den Desktop),

und dann gab es noch den Versuch, FreeBSD und NetBSD zu "debianisieren"
(d.h. ein *BSD mit einem GNU-Userland zu umgeben, angefangen von der
glibc), aber ich weiss nicht, ob das Projekt noch lebt. (Sieht so aus:
www.debian.org/ports/kfreebsd-gnu)

Letzteres erinnert mich an meinen manchmal gehegten Wunsch, den
kommerziellen Support von Linux (z.B. Oracle) mit dem robusten,
performanten FreeBSD-Kernel zu "versoehnen".

FreeBSD (und NetBSD, vielleicht die anderen auch) implementiert im Kenel
die Linux-ABI, d.h. Linux-Applikationen koennen Systemrufe an den
FreeBSD-Kernel geben, der sich fuer sie wie ein Linux-Kernel verhaelt.
Damit nicht alles durcheinander kommt (z.B. eine Linux-Applikation die
Linux-Bibliotheken findet), wird alle, was zu Linux gehoert, unter
/compat/linux abgelegt, wenn ein Linux-Programm von dort gestartet wird,
findet in etwa ein chroot statt (so dass z.B. /usr/lib-Libraries unter
/compat/linux/usr/lib gefunden werden). Es gibt einen Port, der linux-base
heiist, und der tatsaechlich von Red Hat einen Haufen Bibliotheken
runterlaedt (z.B. die glibc) und unter /compat/linux installiert.

BTW: Ich habe gerade unter den Linux-Ports fuer FreeBSD nachgeguckt
(http://www.freebsd.org/ports/linux.html), gefunden, dass es mindestens
fuenf linux-base-Packages gibt (Red Hat 7.3, 8.0. SuSE 9.1, 9.2, 9.3),
Pakete fue StarOffice oder Linux-Opera, und Ports, die
Intel-Linux-Compiler (C, C++, Fortran) installueren - so dass sie native
FreeBSD-Code erzeugen!

Ich muss fairerweise sagen, dass ich nicht genuegend Alltag als SysAdmin
zur Zeit habe, um ein kompetentes Urteil ueber Linux-2.6-Kernel abzugeben.
Mein Alltag mit Linux-2.4 und frueher war doch oft etwas frustrierend, so
zuverlaessig und performant wie von anderen Unix-Systemen (inklusive
FreeBSD) gewohnt waren sie nicht. Wuerde gerne mal hoeren, ob SysAdmins
wiklich im Alltag sagen koennen, dass 2.6 ein grosser Schritt vorwaerts
ist, besonders ob Memory- und Prozessmanagement jetzt alltagstauglicher
sind.

Grundlegend, immer wenn ich in Linux-Kernel-Quellen rumlese und debugge
(zuletzt vor ein paar Monaten, SuSE Enterprise 8.0 und iSCSI betreffend),
habe ich das Gefuehl eher genialistischen Hackercode als solide,
durchschaubare Programmierarbeit vor mir zu hben, das staerkt auch nicht
gerade mein Vertrauen.

Gruss
Peter