Wenn ich das richtig verstanden habe, sucht OSX nicht aktiv nach "ich muss 10 Sektoren beschreiben, also suche ich einen Platz wo es passt" sondern "ich muss 10 Sektoren schreiben, also beschreibe ich den 1. freien Sektor und wenn dann da leider keine 10 Sektoren hintereinander frei sind, dann schreibe ich eben auf den nächsten weiter, bis alle 10 Sektoren geschrieben wurden".

Dieses ist natürlich ein schönes Bild, das völlig logisch scheint. genauso wie das Bild, das die Defragmentierungsprogramme grafisch präsentieren (viele verstreute belegte Sektoren, fragmentierte Dateien in rot). Die sind recht einfach zu verstehen und wenn man die so belässt, dann haben Defragmentierungen einen grossen Effekt, weil es ja völlig einleuchtend ist. Betrachtet man sich das genauer bei moderenen Systemen ist es bei weitem nicht mehr so. Nur als Beispiele:
- Woher weiss das OS wie viele Sektoren die Zieldatei haben wird? Wenn ein Programm eine Datei schreibt, dann sagt das Programm dem OS nicht vorher Bescheid, wie gross die wird. Außerdem kann eine Datei ja auch mit der Zeit grösser werden.
- Es gibt zwei Arten von Fragmentierung. Einmal die Fragmentierung einer Datei (die hast Du hier betrachtet) und die Fragmentierung des freien Platzes auf der Platte).
- Auch wenn keine Datei in sich fragmentiert ist, der Lesekopf muss ständig hin- und herspringen, da viele Dateien gleichzeitig geöffnet sind.
- Dateien (gerade größere) werden nicht unbedingt am Stück gelesen, sondern zwischendurch dann noch andere.
- Gerade sehr große Dateien (über 20MB, ist natürlich eine willkürliche Grenze) werden nicht am Stück gelesen und der Kopf muss sowieso springen.
- Sinnvoll wäre es, die Fragmente von Dateien genau in der Reihenfolge auf die Platte zu legen, wie sie gebraucht werden, d.h. eine Fragmentierung der Dateien wäre sogar geschwindigkeitsfördernd. Allerdings ist diese Reihenfolge natürlich immer anders und nicht generell festzulegen.
- Die Caching-Methoden vom Betriebssystem und unabhängig davon von der Platte selber versuchen die Effekte soweit möglich zu mildern, d.h. aber auch, dass die physikalischen Zugriffe gar nicht so einfach vorausgesagt werden können.
- Neben der automatischen Defragmentierung von kleinen Dateien unter OS X verschiebt OS X auch noch die am häufig verwandten Dateien in den Bereich der Platte, der am schnellsten ist.

Also im Prinzip ziemlich kompliziert das alles.
Im Endeffekt: Moderne Systeme haben so viele Dateien gleichzeitig auf und greifen auf die unterschiedlichsten Dateien zu, dass der Kopf sowieso ständig springen muss. Das ganze wird durch Caching, autom. Defragmentierung gemildert und eine vollständige Defragmentierung bringt nahezu keinen Geschwindigkeitsvorteil, auch weil es keine optimale Struktur gibt und völlig defragmentierte Dateien und Platte gar nicht optimal sind. Nur bei sehr vollen Platten oder Spezialfällen (Videoschnitt mit sehr grossen Dateien) kann es zu Geschwindigkeitsnachteilen durch Fragmentierung kommen. Aber auch dann ist "Backup erstellen und zurückkopieren" einfacher als "Backup erstellen und defragmentieren".

X11 ist doch ein Fenstermanager und wird sogar  mitgeliefert. Du meinst wahrscheinlich die Kategorie KDE oder Gnome. Die nutzen Bibliotheken, wenn diese portiert sind, kann man die auch nutzen, siehe zum Beispiel http://www.golem.de/0701/49982.html.
Ja, man kann via Terminal SSH und FTP nutzen.
Auf der VPCN-Seite steht doch, daß Darwin / Mac OS X unterstützt werden.
Mac OS X kannst Du Dir nicht selbst kompilieren, da nicht der gesamte Quellcode zugänglich ist. Darwin (ohne Aqua und vieles mehr) aber schon, das ist die Grundlage, auf der Mac OS X basiert und damit ist der Kernel offen, veränder- und kompilierbar. Nutzt Dir aber als Endanwender nichts, es sei denn Du wendest halt wirklich Darwin an.
Selbstverständlich kannst Du am Mac Programme kompilieren, wenn Du einen Compiler installiert hast. Also zum Beispiel die mitgelieferten Developer-Tools installierst.
Natürlich kann man Bibliotheken installieren, wenn sie denn kompatibel sind. Du kannst aber nicht Linux-Bibliotheken einfach überstülpen.

Irgendwie  hat keine der Fragen etwas mit der Eingangsfrage zu tun, inwieweit Mac OS X ein echtes Unix ist. Was ist überhaupt ein echtes Unix? Das scheint mir fast schon eine metaphysische Frage.

... das ist ja noch ein sehr interessanter Thread geworden. Bis auf die Lebensdauer und die Datenkonsitenz scheinen die Flashspeicher ja durchaus im Vorteil zu sein.

Was macht denn OSX bei einer Datei, die mehr als 20 MB groß ist?

Ganz einfach: Nichts. 

Muss man also doch ab und an defragmentieren

Das lohnt nicht. Siehe Mac'n'Roll-Betriebshandbücher, Systempflege.

wird das auch durch die "Systemroutinen", die um 3 Uhr nachts laufen gemacht?

Nein. Die Systemroutinen sind nur für Server gedacht und für Leute, die regelmäßig die Kommandozeile (im Terminal) nutzen.

Ich dachte, dass das "Journaling" das ist, was die Platte automatisch defragementiert

Nein, Journaling ist etwas ganz anderes, nämlich ein sehr raffiniertes Verfahren, das Dateisystem auch bei einem plötzlichen Systemausfall in einem wohldefinierten Zustand zu halten.

Findet mitten beim Schreiben vom Daten eine "Katastrophe" statt, nämlich ein Stromausfall oder ein Systemabsturz (Kernel Panic), dann kann mit Hilfe des Journals der Zustand des Dateisystems beim Wiederanlauf innerhalb weniger Sekunden sauber wiederhergestellt werden.

Ohne Journal würde das Betriebssystem beim Wiederanlauf für alle Platten die Funktion "Volume reparieren" (fsck) aufrufen, was bei einer größeren Datenmenge mehrere Stunden dauern kann und oft auch scheitert, weil Lücken in den Daten vorhanden sind.

Das Journal ist eine zweite Datenstruktur, die bei jedem Schreiben der Nutzdaten mitgepflegt wird. Die Reihenfolge der Zugriffe auf Nutzdaten und Journal ist so ausgeklügelt aufeinander abgestimmt, dass das System zu jeder Zeit unterbrochen werden darf. Findet eine Unterbrechung statt, kann das System beim Wiederanlauf aus dem Journal vollständig rekonstruieren, was es zuletzt gemacht hatte. Je nachdem, welche Bruchstücke von Nutzdaten noch da sind, wird der zuletzt laufende Vorgang entweder sauber zu Ende gebracht oder sauber rückgängig gemacht. Es gibt übrigens nur wenige Spezialisten auf dieser Welt, die die technische Fähigkeit haben, ein unter allen Umständen korrekt arbeitendes Journal-Verfahren zu programmieren.

Zurück zum anderen Thema:

Wenn ich das richtig verstanden habe, sucht OSX nicht aktiv nach "ich muss 10 Sektoren beschreiben, also suche ich einen Platz wo es passt"

Doch, im Prinzip tut es das. Es wäre ja dumm, es nicht so zu machen, denn ansonsten würde ja eine schlimme Fragmentierung entstehen. Trotzdem besteht auch in diesem Fall immer noch eine gewisse Restwahrscheinlichkeit für Fragmentierung, denn (a) kann die Platte irgendwann so voll werden, dass die vorhandenen "Lücken" nicht mehr ausreichen und (b) kann sich das System "verschätzen" wenn mehrere große Dateien gleichzeitig geschrieben werden.

dass es dann alle X Minuten die Zugehörigkeit der Dateien überprüft und dann wenn er eben sieht, dass dort am Anfang der Platte ein Sektor beschrieben ist aber der Rest der Datei am Ende, dass es dann den Inhalt des 1. Sektors auf die letzten Sektoren kopiert.

Nein, mir ist kein System bekannt, das so arbeiten würde. Das würde die Plattenleistung ziemlich in den Keller treiben, denn das System kann ja nicht im Voraus wissen, dass die Platte gerade "Zeit und Gelegenheit" hat, eine so aufwändige Kopieroperation durchzuführen.

Mac OS X verwendet ab Version 10.3 tatsächlich automatische Defragmentierung, aber das läuft anders: Wenn (a) ein Programm eine Datei öffnet und (b) die Datei geschrieben werden darf aber im Moment nur zum Lesen offen ist und (c) kein anderes Programm die Datei geöffnet hat und (d) die Datei kleiner als 20 MB ist und (e) die Datei fragmentiert ist und (f) das System mindestens seit 3 Minuten läuft, dann und nur dann verschiebt das System die Datei in einen nicht gestückelten Bereich der Platte, der groß genug ist.


Die Schlussfolgerung, dass bei einer Flash-Disk Fragmentierung keine Rolle mehr spielt, ist aber richtig. Bei so einer Platte darf das System "wild drauflosschreiben", ohne auf Fragmentierung zu achten. Man könnte tatsächlich die Verfahren zur Fragmentvermeidung abschalten und so Schreibvorgänge noch schneller machen.

Es könnte allerdings sein, dass solche Platten intern neue Verfahren brauchen, die sicherstellen, dass sich alle Speicherbereiche gleichmäßig "abnutzen". Wie gesagt ist die Anzahl der physischen machbaren Speichervorgänge begrenzt. Die hierfür benötigte Rechenzeit dürfte aber sehr gering sein und sie findet parallel im Flash-Disk-Controller und nicht im Rechner statt.

Was ich bei SSDs interessant finde sind diese "toten Sektoren", die dann aktiviert werden, wenn ein Sektor auf der Platte den Geist aufgibt.

Wie MacFlieger schon erwähnt hat, funktioniert das bei normalen Festplatten ganz genauso. Bei Flash-Disks ist dies nur wesentlich wichtiger, da Flash-Speicherzellen eine sehr viel geringere Lebensdauer als Magnetplatten haben.

Das größte Hindernis beim Einsatz vom Flash-Speichern ist (neben dem 100-fach höheren Preis) die geringe Anzahl möglicher Schreibzyklen.

Eigentlich sollte man auch in der Lage sein, das Journaling von OSX abzustellen, denn das wird ja dank der SSD, die überall die gleiche Zugriffszeit hat ja unnötig.

Nein, ganz im Gegenteil. Journaling ist bei solchen Speichermedien noch wichtiger, da im Falle eines Stromausfalls eine Flash-Disk keine technischen Tricks verwenden kann, um die letzten Schreib-Cache-Inhalte noch zu sichern (es soll Platten geben, die hierzu Reststrom aus ihrer Rotationsenergie erzeugen). Die Versorgung mit Daten endet sozusagen noch "abrupter".
Ich vermute, Du hast den Begriff Journaling mit irgendetwas anderem verwechselt.

Irgendein Wahnsinniger hat doch bestimmt schon so eine SSD in ein MacBook eingebaut. Wo ist der Testbericht?