kirjoittaessani

Naja. Mit dem Spruch macht die Stadt Werbung für die gelben Säcke, genauer gesagt: dafür, sie erst am Abfuhrtag an die Straße zu stellen. Damit man das nur so weit mißversteht, wie die Marketingabteilung es gerne möchte, haben sie im Layout etwas abgesetzt noch das Wörtchen gelben untergebracht.

Aber darum geht es mir eigentlich gar nicht. Mir doch egal, welchen Werbespruch sie verwenden; nur: die gelben Säcke nerven mich. Damit meine ich nicht die vielfältige Kritik am Dualen System Deutschland, sondern ganz platt die Säcke selbst. Sie sind nicht nur dünner und reißfreudiger als die billigsten blauen Säcke aus dem Supermarkt, sondern auch stetes Hindernis: in einem üblichen Küchenmülleimer (im Spülenschrank) kann man sie vielleicht zur Hälfte füllen, danach darf man entweder einen neuen nehmen oder ihn ein paar Tage offen weiterbefüllen. Und danach -- abgefahren wird ja nur alle zwei Wochen -- sammelt man sie dann irgendwo in der Garage oder dem Keller. Pech für alle, die nur eine kleine Mietwohnung (und vielleicht einen pingeligen Vermieter) haben.

Bis zu meinem Umzug habe ich ja noch geglaubt, es sei üblich, Verpackungen in gelben Mülltonnen zu entsorgen. Jeder hat ein Recht auf Naivität!

Eigentlich weiß ich das ja schon länger, aber heute ist es mir wieder schmerzhaft bewußt geworden: Interpretierte Sprachen1 sind zur Entwicklung ernsthafter Programme ungeeignet. Für Prototypen, einen schnellen Hack, oder als Shell-Skript-Ersatz sind sie eine feine Sache, aber nicht für echte Programme.

Man hört oft, Computer sind heutzutage so schnell, daß das schlechtere Laufzeitverhalten nicht ins Gewicht fällt, und falls doch ein paar Stellen kritisch sind, so ist das auch kein Problem: die Sprache kann C-Routinen aufrufen. Aber darum geht es nicht. Die echten Nachteile liegen nicht in der Ausführungsgeschwindigkeit, sondern in der fehlenden statischen Prüfung des Codes. Wenn man in einer kompilierten Sprache Quatsch schreibt, dann kann man darauf hoffen, daß der Compiler das bemerkt. In manchen strengeren Sprachen2 läßt der Compiler weniger Quatsch durchgehen als in nachgiebigeren3, aber es gibt erstaunliche viele Sorten Quatsch, die jeder Compiler findet. Interpretierte Sprachen kennen keinen Compiler, deswegen finden sie den Quatsch erst zur Laufzeit. Wenn sie ihn finden: Es gibt viele Pfade durch ein Programm, und einige davon werden nur selten benutz; deshalb ist es einfach, völlig vergurkte Programme zu schreiben, zu installieren, und zu benutzen. Es heißt dann oft Deshalb brauchen wir Tests, aber so nützlich Tests auch sind, so haben sie doch gewichtige Nachteile (jedenfalls wenn sie die einzige Möglichkeit sind, Fehler zu finden: Zuerst müssen sie überhaupt geschrieben werden. Ein Compiler versteht die Sprache, aber der Entwickler muß alle nötigen Testcases von Hand schreiben. Dabei kann man leicht etwas übersehen, und noch leichter aus Bequemlichkeit zu wenige (oder gar keine) Tests schreiben. Zweitens braucht das Abarbeiten der Tests Rechenzeit -- wahrscheinlich mehr, als man durch den fehlenden Compilerlauf gespart hat; und das Schreiben kosts Entwicklerzeit, und zwar eine Menge. Schließlich findet der Compiler oft einfach andere Fehler als Tests, und wenn man beides einsetzt, findet man mehr Fehler.

Ja, und dann gibt es noch das Problem mit externem Code. Bibliotheken, Module, oder wie man ihn auch nennen will. APIs sollten sich nicht ändern (jedenfalls nicht ohne guten Grund), aber manchmal tun sie es eben doch. Für gewöhnliche, binäre Programme gibt es wohldefinierte Mechanismen, um verschiedene Versionen einer Bibliothek gleichzeitig vorzuhalten, damit ältere Programme immer noch laufen. Einen entsprechenden Mechanismus für Python kenne ich nicht, und so ungewöhnlich ist es nicht, wenn ein sauber installiertes Modul mit ImportErrors um sich wirft. Wenn man eine solche Methode entwickeln wollte, hätte man auch mit einem zusätzlichen Problem zu kämpfen: Wenn ein Programmierer eine shared library verlinkt, dann nimmt der Linker automatisch die neueste installierte Version dieser Bibliothek. Die Versionsnummer wird dann in dem kompilierten Programm verewigt, und wenn man es irgendwann später startet, wird die richtige Bibliothek benutzt. Es liegt aber gerade im Wesen einer interpretierten Sprache, daß der Programmcode nur vom Programmierer verändert wird. Wenn dieser also nicht von Hand eine bestimmte Bibliotheksversion anfordert, dann tut das auch keine andere Instanz.

Im Ernst: man sollte Werkzeuge verwenden, die für die Aufgabe geeignet sind, anstatt sich verzweifelt an seinen Hammer zu klammern und überall Nägel zu sehen.

1. z.B. Python [↩]
2. z.B. Ada [↩]
3. z.B. C [↩]

Ärgerlich, wenn der Rechner allnächtlich den mühsam zurechtgezimmerten Code löscht. Praktisch, wenn alle Änderungen in der Code-Datenbank gespeichert sind und man zu jedem beliebigen Zeitpunkt zurückgehen kann. Wunderlich, wenn zusammen mit dem Code auch alle seine Spuren in der Vergangenheit verschwunden sind.

Jetzt habe ich über Monate immer mal wieder ein, zwei Stündchen darauf verwendet, das Leck zu finden. Heute war ich endlich erfolgreich:

In the normal fast-forward case the behavior remains unchanged. However, now local modifications and commits will be erased, and upstream rewrites are handled smoothly.  This ensures that the upstream
branch is tested as expected.

Argh! Was soll das denn? Was ich teste, möchte ich bitteschön selbst entscheiden. Und wenn ich wirklich Upstream testen will, dann lege ich schon einen passenden Branch an. Aber es kann doch nicht sein, daß die Software das für mich entscheidet, und dann auch noch meinen Code aus der Datenbank löscht!

The certificate could not be verified for unknown reasons. Kann mir bitte mal einer sagen, was das soll? Was bringt einen Webbrowser -- oder dessen Programmierer -- auf die Idee, ein Zertifikat abzulehnen, ohne zu sagen warum? Und jetzt kommt mir doch bitte nicht mit Unwissen. Um ein Zertifikat zu akzeptieren, muß man gewisse Tests durchführen. Man will sicher den einen oder anderen Hash-Wert berechnen, Domainnamen vergleichen, und natürlich soll ein Zertifikat von einer vertrauenswürdigen Instanz unterschrieben sein.

Am Ende wird der Computer nicht nein sagen, weil es ihm in den Ohren klingelt oder sein Handrücken kribbelt. Wenn er das Zertifikat ablehnt, dann deshalb, weil einer der besagten Tests fehlgeschlagen ist; und weil an dieser Programmstelle genau bekannt ist, wo der Hase im Pfeffer liegt, kann ich das bittesehr auch dem Benutzer mitteilen. Der steht nämlich andernfalls ganz schön dumm da und wird im Zweifel die Warnung einfach wegklicken, statt das eigentliche Problem zu beheben. Dann kann ich mir den ganzen Zertifikatskram aber gleich schenken: einen Sicherheitsgewinn habe ich nämlich nur, wenn der Benutzer solche Warnungen beachtet.

Edit: Wie Heise heute berichtet, hat eine Studie ergeben, daß die Warnungen in der Tat meist weggeklickt werden.

Heute habe ich den ganzen Vormittag damit zugebracht, nach einem Konfigurationsfehler zu suchen: ich wollte einige Benutzer aus einem Server aussperren. Dazu habe ich Pluggable Authentication Modules (kurz: pam) verwendet. Mit pam kann man tolle Sachen machen, zum Beispiel den Login nur von bestimmten Rechnern aus zulassen, oder nur zu bestimmten Uhrzeiten, oder nach einem Haufen sonstiger Kriterien gehen. Das, was ich wollte, ist viel einfacher: ein Benutzer darf rein, alle anderen müssen draußen bleiben.

Nur: es klappte nicht. Egal, wie ich an der Konfiguration gedreht habe, das System hat immer alle reingelassen. Nach der Mittagspause bin ich dann über diesen Satz in der Dokumentation von rlogin gestolpert:

The login process is an instance of the login(1) program, invoked with the -f option if authentication has succeeded.  If automatic authentication fails, the user is prompted to log in as if on a standard terminal line.

Im Klartext: zuerst werden die ausgefuchstesten Bedingungen überprüft; wenn die sagen: komm rein, dann bist du drin. Wenn die aber sagen: du nicht, dann darfst du dein Paßwort eingeben und bis trotzdem drin. Na toll.

Wer denkt sich denn soetwas aus?

Gerade habe ich den neuesten Treiber für meinen Scanner installiert. Dabei bin ich in ungläubiges Staunen verfallen: das Installationsprogramm beendet doch tatsächlich sämtliche Programme, die auf dem Rechner laufen.

Hallo? In welchem Jahrhundert leben wir? OK, zu Zeiten von System 7 war das normal, aber ich dachte, diese Zeiten seien vorbei. Was soll ich denn ohne iTunes machen? Unglaublich.

Es gibt sicher viele Arten, den Sonntagmorgen zu verbringen. Aber eine der schönsten ist ein Frühstück in netter Runde in einem schönen Café.
So bin ich denn gestern früh in die Stadt gefahren — zugegeben, die Uhrzeit war schon zweistellig. Vor dem Eingang des Cafés habe ich schon die ersten beiden bekannten Gesichter getroffen. Drinnen haben wir dann nach einem Platz für vielleicht ein Dutzend Leute gefragt. Der junge Mann wollte sich bei seinem Chef erkundigen.
Das sei schlecht, wußte er nach kurzer Zeit zu berichten: es sei sonntagvormittags immer sehr voll. Im Moment war das zwar nicht der Fall, und ein Schild reserviert konnten wir auch nur auf einem einzigen Tisch entdeckten, aber sei's drum. Wir haben uns einfach den größten freien Tisch (sechs Plätze) gesucht und auf den Rest gewartet. Der kam dann auch nach und nach, und noch bevor unsere Bestellungen eingetroffen waren, wurde der Tisch zu klein. Wir waren natürlich nicht faul und haben ihn flugs mit dem Nachbartisch verlängert. Das sah das Personal nicht so gerne, es gab ein wenig Gegrummel.
Dann kam auch das Essen, und wir haben uns erstmal unserem Frühstück gewidmet.
Später kamen dann noch ein paar Leute dazu, und einer von uns machte sich auf, einen weiteren Tisch zu holen. Diesmal stürmte der Chef eiligst herbei und rief schon von der Theke: Bitte nicht! Er erzählte dann etwas von Kinderwagen, die dann nicht mehr vorbeikämen, aber das mag ich nicht so recht glauben — wir hätten den Durchgang kein bißchen schmaler gemacht, als er eh schon war.

Bei uns ging jedenfalls erstmal das Kopfschütteln los: Wollen die eigentlich kein Geld verdienen? Immerhin haben wir locker einen dreistelligen Betrag dagelassen, und das war sicher nicht der letzte Sonntag, den wir gemeinsam frühstücken — allerdings der letzte in diesem Café. Andernorts ist man sicher flexibler.

Letzte Woche hat mein DSL-Router angefangen, sich zu rebooten. Nicht einmal, sondern permanent. Damit war's erstmal wieder Essig mit Internet. Ich habe an Überhitzung gedacht und ihn erstmal abgeschaltet.
Leider ging die Sache am nächsten Tag genauso weiter. Irgendwann ist mir dann aber aufgefallen, daß das nur bei bestimmten Seiten passiert. Die von 40something ist zum Beispiel dabei. Aber nur, wenn ich Safari benutze. Na toll.

Eine kurze Google-Recherche führte zu dem Ergebnis, daß das bei diesem Gerät schonmal vorkommt. Vielleicht auch nur, wenn das WLAN eingeschaltet ist — wobei dann wiederum egal ist, ob man es auch benutzt. Abhilfe gibt es leider keine — vielleicht hilft es, WLAN auszuschalten, aber dann habe ich ein Kabel quer im Zimmer.

Ich bin begeistert. Offenbar gibt es also nicht nur Bananensoftware, sondern auch Bananenhardware. Vielleicht hilft es ja, ein paar Äpfel danebenzulegen.

Als ich am nächsten Tag Kollegen davon erzählt habe, sagten die mit größter Selbstverständlichkeit, daß spontane Reboots bei allen Herstellern zum Programm gehören.

Ich verbringe meine Zeit derweil mit Kopfschütteln — es kann doch nicht sein, daß es Standard ist, Produkte mit dermaßen dicken Fehlern auf den Markt zu bringen. Gibt's denn niemanden mehr, der Wert darauf legt, gute Arbeit abzuliefern?

Das ist doch echt nicht wahr.

Wenn Finja prokrastiniert, ist das zwar schlecht für ihre Hausarbeit, aber gut für ihre Blogleser; die bekommen auf diese Weise nämlich einen ganz aufschlußreichen Artikel über die Rolle Islands für die Weltwirtschaft geliefert. Alle, die jetzt keine sagen wollen, haben natürlich unrecht (dafür bräuchte man auch keinen Artikel); Kanarienvogel träfe es schon eher.

An einer Stelle mußte ich aber doch kräftig den Kopf schütteln:
Ihre privaten Schulden sind inzwischen doppelt so hoch wie das - schon kräftig gestiegene - verfügbare Einkommen.
Hallo? Schonmal was davon gehört, daß man Größen verschiedener Dimension nicht vergleichen kann? Offensichtlich nicht. Liebe Herren Reis und Nikolov: Schulden haben gemeinhin die Dimension Geld, Einkommen hingegen Geld pro Zeit. Die Aussage, das eine sei größer als das andere, ist ungefähr so sinnvoll, wie der bekannte Spruch Nachts ist es kälter als draußen; um den Vergleich ziehen zu können, muß man das Einkommen schon auf einen Zeitraum beziehen. Gut, das werden die beiden wohl gemacht haben, aber warum sagen sie uns dann nicht, ob sie Wochenlohn, Monats- oder Jahreseinkommen gemeint haben?

Ein Stückchen tiefer tun sie es dann schon wieder:
Für Stirnrunzeln sorgen vor allem Islands Auslandsschulden: Sie liegen mehr als vier Mal höher als die laufenden Einnahmen aus Exporten, die traditionell vor allem Fisch und Aluminium umfassen
Für Stirnrunzeln sorgt hier vor allem die Dimensionsanalyse, die wiederum feststellt: Schulden sind Geld, laufende Einnahmen aber Geld/Zeit, erstere können also gar nicht vier Mal höher als letztere sein.
Im übrigen beschleicht mich hier der üble Verdacht, daß selbst unter Berücksichtigung des korrekten Zeitraums (ich vermute mal: ein Jahr) immer noch eine falsche Aussage dasteht, weil die Auslandsschulden gar nicht viermal höher als die jährlichen Exporte, sondern nur viermal so hoch wie diese sind.
Aber da kann ich mich natürlich auch irren.

Warum muß eigentlich jedes Unternehmen auf seinen Webseiten Produkte und Lösungen anbieten? In der chemischen Industrie könnte ich das ja noch verstehen, aber sonst? Rühren die grundsätzlich alles, was die Fabrikhallen hergeben, in Wasser ein?
Was die Produkte angeht, habe ich aber des öfteren auch so meine Zweifel. Was produziert z.B. eine Bank?
Da fällt mir ein: gibt es eigentlich Neusprech-Kurse bei der Volkshochschule?