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.

Nagios lebt

11/11, S. 6: Ich lese in den News des Linux-Magazins, dass Sie Icinga als Nagios-Nachfolger bezeichnen. Das ist falsch! Nagios befindet sich in aktiver Entwicklung. Gerade ist die Nagios World Conference in den USA zu Ende gegangen. Dort wurden viele Neuerungen rund um Nagios XI und Nagios Core vorgestellt.

Daher finde ich es nicht fair, wenn Sie bei Icinga von einem Nachfolger sprechen, denn Nagios ist nicht tot. Vielmehr ist Icinga ein Fork von Nagios, nicht mehr und nicht weniger.

Christian Mies, per E-Mail

Summa cum laude

11/11, S. 85: Mit großem Interesse habe ich den Beitrag über vier Literaturverwaltungen gelesen. Bei uns an der Universität Kassel entstand die Software Bibsonomy http://www.bibsonomy.org . Sie ist Open Source und hat inzwischen über 500  000 aktive Nutzer.

Sie bietet Social Bookmarking und Literaturverwaltung in einem. Daneben importiert sie Daten aus vielen wissenschaftlichen Datenbanken. Der Anwender kann mit der Software Literaturlisten online teilen oder auf Internetseiten publizieren. Ein Beispiel für eine solche Publikationsliste ist unter http://www.kde.cs.uni-kassel.de/pub zu finden.

An der Unibibliothek in Kassel haben wir zudem das Bibsonomy-Derivat PUMA als Online-Service für Studenten und Wissenschaftler entwickelt: Forscher können damit ihre Publikationen auf dem Dokumentenserver veröffentlichen. Dissertationen, Tagungsbände und vieles mehr ist somit im Open-Access-Modell verfügbar und auch bei Google Scholar sichtbar.

Stefan Drößler, per E-Mail

Unterschätzte Skriptsprachen

11/11, S. 88: Im Rechtsartikel “Einer für alle” finde ich einige Zeilen sehr salopp formuliert, teilweise sogar falsch. Python-Programme etwa muss der Entwickler nicht immer im Quelltext ausliefern. Der Interpreter gibt sich auch mit dem Bytecode, also den »*.pyc« -Dateien zufrieden. Doch dieser Bytecode lässt sich wieder zu Quelltext dekompilieren. Das gilt für Java genauso.

Daneben verwendet der Autor Fred Andresen den Begriff “klartext-interpretierte Skriptsprachen” und schreibt über diese: “Zudem ist die Ausführungsgeschwindigkeit so langsam, dass man bei umfangreichen Applikationen selbst auf neuesten Rechner-Boliden nicht guten Gewissens darauf setzen kann.” Was darf man unter klartext-interpretierten Skriptsprachen verstehen? Tcl und Shell sicherlich. Python und Ruby sind es nicht, denn sie verwenden Bytecode. Beim Leser bleibt leicht hängen: “Richtige Programme schreibt man mit C oder C++”. Das ist ein Vorurteil, mit dem man als moderner Programmierer immer wieder konfrontiert ist. Diese Ansicht ist jedoch veraltet: Skriptsprachen machen die Entwicklung um einiges schneller. Wird die Laufzeit der Software zu lange, hilft meist gezieltes Auswerten der Ausführungsgeschwindigkeit und anschließendes Optimieren weniger Codezeilen.

Thomas Güttler, per E-Mail

Eintönig

12/11, S. 60: Ich frage mich, warum Ihr Source-Highlight in den Tooltipps fünf Sterne gebt, aber Eurem eigenen Tipp nicht folgt. Der einzige, der sich teilweise die Mühe macht, Syntaxhervorhebung in seine Artikel zu bringen, ist Perlmeister Mike. Ansonsten gibt sich aller Quelltext im spröden Charme der 70er Jahre.

Daniel Pfeiffer, per E-Mail