|
|
|
|
|
|
Auf den Punkt gebrachtLeserbriefe |
|
Ich bin gerade (relativ erfolglos) aufgrund der Nachfrage eines prinzipiell umstiegswilligen Kunden auf der Suche nach einer Finanz- und Lohnbuchhaltung, die unter Linux läuft.
Markus Wolff, per E-Mail
Spontan fallen mir zu diesem Themenkreis gleich mehrere Programme ein: SQL-Ledger ist ein Warenwirtschaftsprogramm in Perl [http://www.sql-ledger.com]. Linux-Kontor [http://www.linux -kontor.de] und Tudo [http://www.bemme.de] sind Java-Programme.
Noch mehr bietet eine komplette Betriebswirtschaftslösung wie Compiere, die haben wir vor einiger Zeit auch in der Brave GNU World vorgestellt: [http://www.compiere.org]
Das waren nur freie Programme, die unter der GPL stehen. Daneben gibt es noch eine ganze Reihe kommerzieller Lösungen, allen voran SAP. Das bedeutet aber oft mit Marschflugkörpern auf Spatzen schießen. (fan)
01/02, S. 47: In Ihrem Artikel "Bitte ein Kibibit!" zitieren Sie das IEEE mit der Aussage: "The use of these prefixes should be restricted to audiences that are familiar with mathematical notations such as 2^10 and (2^10)^n. They should not ordinarily appear in the descriptive literature [...] sold to the general public." Sie machen dazu jedoch keine konkrete Quellenangabe.
Können Sie mir sagen, in welchem Dokument ich die Originalaussage finde?
Matthias Bernges, per E-Mail
Es handelt sich um das Dokument "P1541 (SCC14) Standard Prefixes for Binary Multiples". Soweit wir informiert sind, können Sie es zwar nicht frei über das Internet beziehen, aber beim IEEE käuflich erwerben. (jk)
04/04, S. 110: Der "Kern-Technik"-Artikel zum Thema USB-Treiber in der Ausgabe vom April 2004 des Linux-Magazins enthält leider einige schwere Programmierfehler. Zum einen ist »usbtest« ein bereits vergebener Name im Standardkernel. Die Kollision hat zwar vermutlich keine schwerwiegenden Konsequenzen, aber die doppelte Verwendung eines Treibernamens ist zumindest verwirrend. Je nach der Konfiguration des Hotplug-Subsystems kann dabei natürlich gerade der falsche Treiber verwendet werden.
Es sollte außerdem zumindest darauf hingewiesen werden, dass bei der Implementierung der Disconnect-Methode bestimmte Regeln der Serialisierung einzuhalten sind. Insbesondere darf ein Return erst dann erfolgen, wenn alle ausstehenden USB-Transfers endgültig beendet wurden. In dem vorliegenden Beispielcode kann ein Prozess gerade »read()« aufgerufen haben und in »usb_control_msg()« blocken. Tritt dann ein Disconnect auf, wird dieser im Kontext des Khubd-Kernelthreads konkurrierend ausgeführt.
Werden dabei die registrierten Objektreferenzen sofort freigegeben, ist der Kernelcrash bereits vorprogrammiert, wenn der wartende Prozess danach irgendwann aufwacht. Zudem vermisse ich einen Hinweis darauf, welche Anforderungen an die Transferpuffer der USB-Requests gestellt werden. Insbesondere müssen diese Puffer zusammenhängend im physikalischen Speicher sein (nicht swapable) und bestimmte Cache-Alignment-Anforderungen erfüllen.
Wie in den verfügbaren einführenden Dokumenten zur Linux-USB-Programmierung ausgeführt ist, müssen die Puffer deshalb durch eigenständige Kmalloc-Aufrufe angefordert werden. Leider fehlt in dem Artikel nicht nur ein Hinweis auf diese zwingende Voraussetzung, die für jeden USB-Transfer gilt. Vielmehr wird im Beispieltreiber in der Read-Implementierung sogar ein Zeiger auf eine lokale Variable auf dem Stack als Transferpuffer an »usb_control_msg()« übergeben.
Je nach der vorliegenden Plattform erfüllt der Stack jedoch keine der oben genannten Anforderungen. Somit ist hier - sowohl durch fehlgeleitete Cache-Flushes als auch durch ungewollten DMA-Schreibzugriff auf nahezu beliebige Bereiche des Hauptspeichers - jede Art von Datenkorruption möglich.
Martin Diehl, per E-Mail
Im Prinzip sind die Aussagen richtig. Allerdings tauchen diese Fehler an zahlreichen Stellen im Kernel - und somit auch in der Treiberlandschaft - ebenfalls auf. (Jürgen Quade)
04/04, S. 72: In dem Artikel "Immer im Takt" beschreiben Sie, dass der Zeitgeber sein Signal dreimal in der Stunde aussendet, und zwar bei 19, 39 und 59 Minuten. Das ist - soweit ich das weiß - aber falsch. Das Signal wird vielmehr im Minuten- oder sogar im Sekundentakt ausgesendet und muss vom Empfänger dreimal - besser noch fünfmal - fehlerfrei hintereinander aufgefangen werden, um die Zeit sicher auszulesen. Es ist nämlich durchaus möglich, dass sich ein Fehler in den Datenstrom einschleicht, der nicht durch die drei Parity-Bits erkennbar ist.
So geschehen beispielsweise im Jahr 2003 beim nationalen Rundfunksender Dutch National Public Television and Radio in den Niederlanden. Die Verantwortlichen waren nicht sehr begeistert, als alle Systeme auf einmal dachten, es sei das Jahr 1983. Für diesen Zeitpunkt waren logischerweise keine Sendungen vorgesehen.
Jan-Willem Michels, per E-Mail
Sie haben mit ihrer Kritik an dem Artikel Recht: Nicht das eigentliche Signal wird dreimal pro Stunde gesendet, der Abruf der aktuellen Zeit erfolgt dreimal. (jre)
04/04, S. 76: Zu dem interessanten Artikel über Interprozesskommunikation habe ich zwei kleine Ergänzungen: Mit dem Signal »0« (Null) kann man feststellen, ob der betreffende Prozess existiert. Das Programm »kill« liefert dann den Rückgabewert »0«, andernfalls einen Fehler. Damit kann man in Shellskripten recht einfach nach Prozessen suchen, ohne die Ausgabe von »ps aux« oder »ps -ef« parsen zu müssen.
Wenn man mal das »nohup« vergessen hat, gibt es auch noch eine weitere Möglichkeit für die Prozesssteuerung: Man kann mit Hilfe von »disown« den Prozess aus der Tabelle der aktiven Jobs der Shell entfernen. Beim Ausloggen wird der Prozess dann nicht beendet. Hat man eine andere Shell als die Bash, ist es auch möglich, sich mittels »kill -9 $$« auszuloggen. In diesem Fall sendet die Shell keine Signale mehr.
Jochen Hein, per E-Mail
04/04, S. 94: Ihr stellt "Hacking - The Art of Exploitation" von Jon Erickson vor. Ein absolut empfehlenswertes Buch für jeden, der sich mit dem Thema Hacken auseinandersetzt und über die Fähigkeiten eines Skript-Kiddie hinauskommen möchte. Glücklicherweise ist das Werk bereits auf Deutsch erschienen: Mitp-Verlag (ISBN 3-8266-1457-7). Nicht nur, dass es für alle, die sich mit dem Englischen schwer tun, leichter zu lesen sein sollte, es kostet in der deutschen Version auch nur 24 Euro. Ihr Titel ist übrigens "Forbidden Code".
Christian Schmitz, per E-Mail
05/04, S. 116: Ich fand einen kleinen Bug im Coffee-Shop. Die folgende Aussage ist seit JDK 1.4 nicht mehr aktuell: "Da JFreechart auf das AWT aufsetzt, ist zumindest ein virtueller X-Server notwendig." Man kann der Virtual Machine mittels »-Djava.awt.headless=true« dem Programm beim Start mitteilen, dass man keinen X-Server hat. Ein kurzer Test mit dem Sun Java Development Kit 1.4.2_03 ergab, dass der Batchmode auch ohne X-Server funktioniert.
Daniel Wunsch, per E-Mail
05/04, S. 18: Im Zusammenhang mit der Lindows-Meldung im News-Teil möchte ich Folgendes anmerken: Die Ersatzdomain für die Niederlande lautet [http://www.lin---s.com] und nicht wie abgedruckt [http://www.lin----.com].
Gerfried Fuchs, per E-Mail
Anmerkung der Redaktion: Lindows sucht nach einem neuen Namen für seine Produkte. Mehr dazu ab Seite 20.
05/04, S. 50: Mit Interesse habe ich in einer der letzteren Ausgaben den Artikel studiert, in dem es um Plattenverschlüsselung mit USB-Sticks ging. So als i-Pünktchen dachte ich mir, dass man nun einen "Fingerprint USB-Stick" nehmen könnte, sodass im Falle eines Stick-Verlusts der Zugang zu den Cypher-Daten nicht möglich ist.
Philipp Morger, per E-Mail
Wie sicher eine Biometrielösung tatsächlich ist, bleibt zumindest umstritten. Immerhin, der Datenschutzaspekt ist auf dem eigenen privaten Rechner weitgehend hinfällig, daher könnte der Fingerabdruck als zusätzliche Sicherheit schon interessant sein.
Eine kurze Suche bei Google fördert auch den Link [http://www.4trust.de] zutage. Da verschlüsselt der Stick die Daten auf dem Stick selbst. Das wäre also quasi eine Plug & Play-Variante: Einfach dieses Ding nehmen (geht angeblich unter Linux), dann rückt es den gespeicherten Schlüssel nur raus, wenn der richtige User seinen Daumen draufhält. (fjl)
05/04, S. 86: Nach meiner Erfahrung spielt das Betriebsgeheimnis bei der Entscheidung, einen Treiber als Closed Source zu vertreiben, eine geringere Rolle. Ein im Artikel nicht erwähnter Aspekt ist die Gewährleistung. Speziell bei empfindlicher und teurer Hardware in der Messtechnik ist es durchaus problematisch, wenn ein Kunde den Treiber manipulieren kann.
Eventuell kann dies zur Zerstörung der Hardware führen. Dem Hersteller wird es schwer fallen nachzuweisen, dass der Kunde durch Änderungen am Treiber den Defekt verursacht hat. Als kommerzieller Anbieter dürfte es auch schwierig werden, sich mit einer Klausel ähnlich der GPL aus der Affäre zu ziehen, um keine Gewähr leisten zu müssen.
Auch mit der Veröffentlichung der Registerbeschreibung gibt es schlechte Erfahrungen. Wenn es beispielsweise nötig ist, die Schnittstellen zu verändern, wird es mit Sicherheit Probleme beim Kunden geben, die dann den Support belasten. Als Debian-Entwickler bin ich natürlich für die Offenlegung der Quellen im Sinne der FSF, aber es gibt gute Gründe, dabei Bauchschmerzen zu haben.
Christoph Baumann, per E-Mail
| Errata |
|
04/04, S. 34: Der Beitrag über die mögliche Denial-of-Service-Attacke in Jabberd enthält einen kleinen Fehler: Der Bug in Jabberd wurde für Version 1.4.2 mit einem zusätzlichen Patch behoben, Version 1.4.3 enthält diese Korrektur bereits. Es hätte also heißen müssen "Betroffen sind die Versionen vor 1.4.3" und nicht "... bis 1.4.3". |