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. Sie veröffentlicht alle Beiträge mit Namen, sofern der Autor nicht ausdrücklich Anonymität wünscht.

Geschwindigkeit gegen Lesbarkeit

03/13, S. 94: Hashes als Strukturen zu benutzen ist wunderbar flexibel, wenn jedes Objekt einen abweichenden Attributsatz haben soll. Wenn ich immer gleiche Strukturen stattdessen als Arrays ablege, ist das sowohl in Laufzeit als auch im Speicherverbrauch deutlich günstiger. Das habe ich selbst getestet.

Schade, dass so was nicht Schule macht! In »Distro« hätte bei den vielen Paketen die zentrale Datenstruktur mit entsprechenden Konstanten genauso lesbar »$_->[PKG]« und »$_->[MTIME]« heißen müssen. Mein Perl 5.16.2 legt von diesen Tupeln 18-mal eine Million in 10 Sekunden an und liest sie jedes Mal alle wieder aus, im Gegensatz zu nur 13-mal bei Zweier-Hashes.

Daniel Pfeiffer, per E-Mail

Was Zertifizierungen testen und was nicht

03/13, S 28: Der Artikel suggeriert, eine Zertifizierung mittels EAL 4 sei ein Ausdruck der Qualität der entstandenen Software: “Haben die Mitarbeiter der Distributoren gut und vor allem nachweisbar gut gearbeitet, dann winkt als Beweis der Qualität eine Zertifizierung …” Dem ist mitnichten so: Die Zertifizierung nach Common Criteria überprüft ausschließlich, ob die im Security Target beschriebene Funktionalität wie beschrieben enthalten ist. Ein wichtiger Unterschied, wie wir bereits in einer SAP-on-Linux-Migration von AIX 5/6 auf damals RHEL 4 leidvoll erfahren mussten.

Da sich die Zertifizierungskriterien nicht signifikant geändert haben, zweifle ich einfach an, dass die gelieferte Qualität objektiv höher ist. Es sind hoffentlich einige Bugs behoben, aber Erfahrungen mit SLES 10 bis SP2 förderten auch Erschreckendes in den von Suse modifizierten Kernelquellen zu Tage – und SLES 10 ist EAL 4+ zertifiziert, nicht?!

Jens Rehsack, per E-Mail

Mega- vs. Mebibyte bei USB-Sticks und anderswo

04/13, S. 110: Die frühen Informatiker fanden es witzig, die SI-Einheiten zu verdrehen, steckte doch in 1 Kilobyte “nur” ein 2,4-Prozent-Fehler. Leider potenziert sich der Fehler, sodass wir bei ehemals unvorstellbaren TBytes bereits 10 Prozent daneben liegen.

Deswegen hat die IEC 1996 aufgeräumt und dem Verkaufstrick der Plattenhersteller Recht gegeben. Seitdem ist genormt, dass SI-Einheiten auch in der Informatik Zehnerpotenzen sind, woran jedermann denkt, wenn er von Gigabytes redet. Die Gnutools halten sich mit »–si« daran, aber es existiert nicht immer die Kurzform »-H« .

Für die nur technisch relevanten Zweierpotenzen hat die IEC die alternativen Namen Kibibyte (KiB), Mebibyte (MiB) und so weiter eingeführt. Die Buhmänner sind jetzt die Betriebssystemhersteller, weil sie den Standard kaum befolgen. So geben die Gnutools auch mit »-h« (»–human« ) falsche SI-Einheiten aus. Sobald man sie aber selber vorgibt, dann nehmen die Gnutools »MB« korrekt als MByte. Aber dass der Benutzer Mebibytes als »MiB« angeben darf, ist nicht mal dokumentiert, sondern nur »M« .

Leider macht’s die Fachpresse nicht besser. Stattdessen werden wir zu meinem Leidwesen mit krummen, schwer erfassbaren Größen gepeinigt – bei TV-Geräten mit Zoll zum Beispiel.

Daniel Pfeiffer, per E-Mail