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!

Actually, I have known this for some time, but today, it has bitten me again: Interpreted languages1 are not suited for application development. Period. Use them for quick hacks, or for prototyping, or in lieu of a shell script. But never for real applications.

People tend to say Computers are so fast today the overhead does not really matter, and if it does for a few inner loops, no problem: our language can interface with C. But that is beside the point. The real disadvantage of these languages is not their (somewhat inferior) execution speed, but their lack of static checking. If you write bogus in a compiled language, chances are the compiler will catch it. Some stricter languages2 will catch more kinds of bogus than more lenient ones3, but there are surprisingly many ways to write bogus that every compiler will catch. Interpreted languages do not have a compile phase, they just throw an exception when encountering bogus at runtime. If they encounter it: There are many execution paths through a program, and some may not be followed very often, making it easy to write, install, and use completely broken software. You may say Well, write tests then, but as useful tests are, they come with large disadvantages when relied upon as the only means of detecting errors: Firstly, they have to be written. A compiler knows about the language, but the developer has to write all necessary testcases by hand. It is easy to overlook something, and it is also very easy to be lazy and write too few tests (or none at all). Secondly, executing tests takes machine time (probably more than what was saved by not compiling), and writing tests takes developer time (lots of it). Finally, the static analysis a compiler provides tends to catch different errors than tests do, so combining the two will simply catch more problems than either method on its own.

Oh, and then there is the problem of external code. Libraries, modules, whatever. APIs should not change (needlessly), but sometimes they do. With ordinary binary code, there is an established way to keep around different versions of a given library, so older programs using an older API can still function. I am not aware of a similar mechanism for Python, so getting ImportErrors from a module that installed just fine is not that unusual. In fact, implementing such a method for an interpreted language would be somewhat more involved than for a compiled one: When a programmer links to a shared library, the linker will take that to mean the latest installed version of that library. The version number is then encoded into the application binary, so the correct library will be used whenever the application is started. However, the very nature of an interpreted language means that the program is not touched by anyone but the developer. So if the developer does not demand a particular version, nothing else does, either. Seriously: use a tool that fits the job rather than clutching a hammer and trying to see nails everywhere.

1. like Python [↩]
2. like Ada [↩]
3. like C [↩]

Unpleasant: night after night, your machine keeps deleting your laboriously developed code. Convenient: everything is in a local git repository, and any point in time may be reconstructed. Strange: not only has the code disappeared, but all traces of its history as well.

In the past few months, I have spent an hour or two almost every week to find the leak. Today, I have met with success:

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! What bally idea is that? I would like to decide for myself what I want to test, thank you very much. If I really want to test Upstream, I will create a branch for that purpose. It is not up to some piece of software to decide in my place, and then remove my code from the repository!

The certificate could not be verified for unknown reasons. Could someone kindly tell me what that is suposed to mean? How on earth does a web browser -- or its programmer -- figure it should reject a certificate, but remain silent as to its motivation? Now, do not tell me it does not know. In order to accept a certificate, certain tests need to be conducted. You probably want to calculate a hash value or two, compare domain names, and verify the certificate has been signed by someone trustworthy.

If the computer eventually says no, that is not due to a tingling in the back. Rather, the certificate is rejected because one of the tests has failed; and a this place in the program, it is exactly known which test failed, so why not tell the user? Otherwise, the problem is pretty hard to fix, so most people probably just click ignore. In that case, I can just as well do away with support for certificates: they only work when the user understands what is going on and heeds error messages.

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?