Leserbriefe

Haben Sie Anregungen, Statements oder Kommentare? Dann schreiben Sie an [redaktion@linux-magazin.de]. Die Redaktion behält es sich vor, die Zuschriften und Leserbriefe zu kürzen. Alle Beiträge werden mit Namen veröffentlicht, sofern nicht ausdrücklich Anonymität gewünscht wird.

Windows-Treiber

02/04, S. 14: Ich bin beim Lesen über den Ndis-Wrapper gestolpert. Leider konnte ich auch damit ein Problem nicht lösen, das ich bei einem IBM T40 mit einer MPCI-Karte Cisco Aironet 350 und Red Hat 9 Professional habe. Diese Karte habe ich mit keinem Treiber zum Laufen bekommen. Angeregt durch Ihren Artikel habe ich im Netz gestöbert und dabei den Linuxant Driverloader [http://www.linuxant.com] gefunden.

Ich habe eine Mail an Linuxant geschrieben. Nach äußerst kurzer Zeit bekam ich eine Antwort von Marc Boucher, der sich freundlicherweise meines Problems annahm und nach sage und schreibe drei Stunden eine Lösung fand. Ich kann jedem nur raten: Bei Wlan-Treiberproblemen schaut euch Linuxant mal an. Der Treiber kostet gerade mal 20 US-Dollar, was wohl mehr als fair ist, denn eine andere Wlan-Karte würde mehr kosten.

Gregor Nebgen, per E-Mail

Fritz-PCI unter Kernel 2.6

02/04, S. 28: Schon seit einer Weile versuche ich Capi bei mir zum Laufen zu kriegen, um mich auf den 2.6er Kernel vorzubereiten. Seit einer Woche habe ich Capi unter Kernel 2.4 erfolgreich im Betrieb. Aber mit einem von Hand installierten Kernel 2.6 bekommen ich das AVM-Modul für die Fritz-Karte nicht kompiliert. Auch Googeln zu diesem Thema hat mich nicht weitergebracht.

Michael Müller, per E-Mail

Das dürfte so lange aussichtslos sein, bis AVM die Capi-Treiber für Kernel 2.6 baut. Das Modul ist ausschließlich für den Einsatz mit Kernel 2.4 gedacht. Sie werden warten müssen, bis AVM die Treiber für Kernel 2.6 anbietet. (mdo)

Plattformen

02/04, S. 28: Im Linux-Magazin finde ich immer wieder Artikel, die mich interessieren. So zum Beispiel "ACPI konkret". Leider finde ich ebenso Behauptungen, welche schlicht falsch sind. So heißt es in der Geschichte über Kernel 2.6: "Kein zweites Betriebssystem läuft auf einer ähnlich breiten Palette von Plattformen."

Das war in der neusten Nummer zu lesen. Ich erinnere mich aber, ähnliche Behauptungen schon in anderen Magazinen gelesen zu haben. Tatsache ist, dass Linux weit weniger Plattformen abdeckt als NetBSD. NetBSD deckt rund 53 Plattformen ab. Bis Linux auf so vielen läuft, dürfte es noch ein Weilchen dauern.

Hanspeter Roth, per E-Mail

Ich denke, ganz so falsch ist diese Aussage nicht. Ich zitiere mal den kompletten Satz: "Kein zweites Betriebssystem läuft auf einer ähnlich breiten Palette von Plattformen, vom Embedded-System über PDAs, PCs bis hin zu Großrechnern." Dieser Satz sagt nichts über die Anzahl der Plattformen, sondern über ihre Bandbreite und Unterschiedlichkeit. Von einer Portierung auf S/390 (Z-Series) oder auf AS/400 (I-Series) ist mir bei BSD nichts bekannt. Es ging an dieser Stelle auch nicht um die Portierungen, sondern um die Skalierbarkeit.

Ich hoffe, dass Sie unsere plakative Aussage pro Linux-Skalierbarkeit nicht als abwertend oder geringschätzend gegenüber anderen Betriebssystemen empfinden. Sie war keinesfalls so gemeint, wir schätzen die Arbeit der BSD-Teams. (fjl)

Linux 2.6

02/04, S. 28: Die von Ihnen angegebene Version »test11« habe ich nicht gefunden, daher habe ich 2.6.1 genommen. Den wollte ich ausprobieren, aber bereits beim Befehl »make menuconfig« kommen etwa vier Bildschirmseiten Errorcode - und er bricht mit »Error 2« ab. Ich habe zur Zeit Suse 9.0 laufen - mit neuem »insmod« - und den 2.4.21. Laut Artikel brauche ich außer den aktuellen Modutils nichts weiter.

Joey Frank, per E-Mail

Mit Suse 9.0 und dem Kernel 2.6.1 sind die Voraussetzungen sehr gut, um den Kernel erfolgreich zu generieren. Nach der kurzen Problembeschreibung könnte es sein, dass auf Ihrem System noch nicht alle notwendigen Pakete installiert sind. Das hängt eben von der Installation ab. Versuchen Sie doch mal die in dem Artikel (siehe Kasten "Kernel 2.6 unter Suse") angegebenen Pakete (per Yast) zu installieren: »gcc«, »make« und »ncurses«. (Jürgen Quade)

GNU/Hurd

02/04, S. 84: Ich wollte nur auf einen kleinen Fehler hinweisen: Thomas Bushnell hat zwar das Hurd-System konzipiert, er ist jedoch schon seit einigen Jahren nicht mehr der Hauptpfleger des Codes, das macht Marcus Brinkmann aus Bochum. Ansonsten muss ich sagen, dass mir die Serie "Projekteküche" ganz gut gefällt (vor allem die Rezepte sind eine nette Idee - leider bin ich nicht besonders gut im Backen, sodass ich das immer nachmachen könnte).

Zeno Gantner, per E-Mail

Dateisystem-Vergleich

03/04, S. 31: Ich möchte euch ein dickes Lob für den Dateisystem-Vergleich aussprechen - da habt Ihr ein ganz heißes Eisen ausgesprochen souverän angepackt und behandelt.

Ich habe nach Jahren mit Ext 2 ein gutes Jahr mit Ext 3 auf Desktop, Router und Laptop rumgehökert und bin damit nie so richtig warm geworden. Aus verschiedenen Gründen wollte ich weder ReiserFS noch JFS, sodass ich Ende letzten Jahres mit Erscheinen von 2.4.24-pre1 und 2.4.25-pre4 meine Arbeitsrechner auf XFS migriert habe und glücklich und zufrieden bin. Das Dateisystem läuft stabil wie eine Mauer, ist schnell und beschert mir durch die intelligente Ablage auch von Kleinstverzeichnissen im B-Tree fünf bis zehn Prozent mehr Festplattenkapazität.

Martin Bock, per E-Mail

Journaling Filesysteme

03/04, S. 31: Zu Ihrer Bewertung von Ext 3 ist einiges zu sagen - insbesondere eins: Sie ist definitiv nicht fair. Wenn Sie statt des standardmäßig eingestellten Modus »ordered« den Modus »journal« verwenden, dürfen Sie sich über die schlechte Performance nicht wundern. Schließlich ist dies eine Option, die keines der anderen Systeme mit sich bringt. Alle anderen Vertreter dieser Gattung arbeiten - jedenfalls soweit ich das gelesen habe - höchstens in einer Betriebsart, die mit »ordered« vergleichbar ist. Das heißt also, sie sichern Metadaten mittels Journal.

Soweit ich gehört habe, enthält die Ext-3-Unterstützung im 2.6er Kernel einige Verbesserungen bezüglich des Zugriffs auf Directories, eine Suche mit Hilfe eines Hash-Verfahrens. In Ihrem Testbericht wurde nichts davon erwähnt.

Boris Jakubith, per E-Mail

Die Entscheidung für den Journal-Modus basiert auf zwei Überlegungen: Wir haben einen 2.4-Kernel verwendet, da 2.6 noch nicht weit genug ist, um tatsächlich vergleichbare Ergebnisse zu liefern. Daher war es unserer Meinung wichtiger, Ext 2 gegen ReiserFS, JFS und XFS antreten zu lassen.

Zweitens wählten wir den Journal-Modus von Ext 3 bewusst und haben mehrmals im Artikel auch darauf hingewiesen, eben weil er der langsamste Modus ist. Wir wollten so das Verhältnis von Sicherheit zu Performance zeigen. Das ist unserer Meinung zulässig, da Ext 3 auf 2.4 ein Update zu Ext2 darstellt. (jre)

Block-Organisatoren

03/04, S. 36: Wir betreiben einen Linux-Cluster mit 68 Dual-Pentium-III und haben XFS den Vorzug vor Ext 3 gegeben. Lokale Filesysteme des Management-Head-Node sind XFS-basiert und in den Cluster hinein per NFS freigegeben (»RPCNFSDCOUNT=68« und ein Prozess/Thread pro Cluster-Node). In unregelmäßigen Abständen kommt der NFS-Server aber vollständig zum Erliegen und die Knoten können auf ihre NFS-Mounts weder lesend noch schreibend zugreifen. Kommandos auf dem Head-Node kehren nie zum Prompt zurück und nur noch ein kompletter Reset des Head-Node bereinigt die Situation. Vielleicht liegt ja in der Kombination XFS und NFS-Freigabe der Grund für unsere unerklärlichen Abstürze?

Christian Griebel, per E-Mail

Zum Export via NFS berichten die Anwender in den einschlägigen Foren immer wieder über Probleme - egal mit welchem lokalen Dateisystem. Vielleicht finden Sie unter [http://oss.sgi.com/archives/linux-xfs/] einen Hinweis, denn bei dieser Problemstellung sind viele Faktoren zu berücksichtigen.

Ansonsten könnten Sie mit den Werten für die MTU (mit »rsize« und »wsize«) experimentieren. Aktivieren Sie zudem die Debug-Meldungen des Kernels und lassen diese auf die Konsole ausgeben. Denn auch der NFS-Server im Kernel könnte für die Hänger verantwortlich sein. Weitere Informationen finden Sie vielleicht auf der Kernel-Mailingliste [http://www.lkml.org] oder auf der für NFS [http://playground.sun.com/pub/ nfsv4/nfsv4-wg-archive/] (jre)

Listing 1: Korrigierte »ProcRead()«

01 static int ProcRead( char *buf, char **start, 02 off_t offset, int size, int *eof, void *data) 03 { 04 int BytesWritten=0, ret; 05 06 ret=snprintf( buf+BytesWritten, (size-BytesWritten), "ProcRead wurde\n"); 07 BytesWritten += (ret>(size-BytesWritten)) ? (size-BytesWritten) : ret; 08 ret=snprintf( buf+BytesWritten, size-BytesWritten, "aufgerufen.\n"); 09 BytesWritten += (ret>(size-BytesWritten)) ? (size-BytesWritten) : ret; 10 11 *eof = 1; 12 return BytesWritten; 13 }

Errata

02/04, S.48: In die Kern-Technik-Folge 7 hat sich ein Fehler eingeschlichen. Dort wird empfohlen, »snprintf()« anstelle von »sprintf()« zu verwenden. Jedoch berücksichtigen der Text und das Listing auf Seite 49 einen wichtigen Unterschied nicht: »snprintf()« gibt nicht die Anzahl der Zeichen zurück, die es geschrieben hat, sondern jene, die es schreiben würde, falls der Buffer groß genug wäre. Für die Berechnung der nächsten zu beschreibenden Adresse beziehungsweise für den noch freien Platz im Buffer sind aber die wirklich geschriebenen Zeichen relevant. Die korrigierte Funktion »ProcRead()« ist in Listing 1 zu sehen.