AK's weblog

OpenBSD ist - wie dem einen oder anderen Leser sicherlich bekannt sein dürfte - ein von NetBSD abgeleitetes Unix-artiges Betriebssystem, das seinen Fokus auf Sicherheit legt. Als Entwickler und Maintainer des mittlerweile halbwegs populären Open-Source-Projekts newsbeuter sehe ich es nicht nur als meine Aufgabe, neue Features zu entwickeln und bestehende Bugs zu fixen, sondern auch einen gewissen Aufwand darin zu stecken, die Software für ein möglichst großes Publikum auch tatsächlich praktisch zugänglich zu machen. Diese Aufgabe hat verschiedene Grundrichtungen. Das ist etwa die einfache Verfügbarkeit für Enduser (da habe ich beispielsweise vor kurzem erst eine Liste von Distributionen, die mit fertigen Paketen kommen, zusammengestellt), eine möglichst durchgängige Internationalisierung und Lokalisierung (so ist newsbeuter in mittlerweile 14 verschiedenen Sprachen verfügbar), oder aber auch, die Kompatibilität zu anderen Systemen als nur die populären Linux-Distributionen zu testen und zu gewährleisten. Letzteres hat dazu geführt, dass newsbeuter unter Linux, FreeBSD und Mac OS X läuft.

Vergangenes Wochenende habe ich mich daran gemacht, die Kompatibilität auch zu weiteren Systemen zu testen. Auf meinem Plan standen konkret NetBSD und OpenBSD. Der Zustand von NetBSD ist kurz geschildert der, dass die Citrus-Implementierung von iconv() in der Art und Weise nicht kompatibel ist, als dass es das spezielle Encoding "WCHAR_T", das von der STFL verwendet wird, nicht unterstützt. Das ist nicht schön, aber verkraftbar, da einerseits die von iconv unterstützten Encodings/Zeichensätze systemspezifisch sind, andererseits man da sicherlich auch (achtung, ungetestet!) die GNU libiconv einsetzen könnte.

Bei OpenBSD bietet sich hier ein völlig anderes Bild: hier scheiterte mein Versuchen, die STFL zu übersetzen, schon daran, dass OpenBSD über keine Implementierung von swprintf verfügt. Etwas verdutzt hab ich dann begonnen, weiterzurecherchieren, weil ich eigentlich der Meinung war, dass OpenBSD eigentlich schon mal die Arbeit des Citrus-Projekts importiert hatte, und bin schon nach kurzem über die nahezu talibanesken Ausführungen eines Herrn uriel, der einen Fanatismus dabei zeigt, auf den Unix-Standardweg für Internationalisierung (nämlich wchar_t + Funktionen darauf) zu verzichten und stattdessen UTF-8 als den Einzig Wahren Weg(TM) anzupreisen. Schließlich habe ich mich rangemacht, und geschaut, welche Funktionen aus wchar.h in NetBSD (die Citrus integriert haben), jedoch nicht in OpenBSD zu finden sind, und bin auf folgendes Ergebnis gestoßen. Dadurch, dass das nicht irgendwelche Pipifax-Funktionen sind, sondern da auch ein konkreter Standard bzw. hinreichend verbreitete Implementierungen dahinterstehen, ist die Liste nach Standards sortiert:

Single Unix Specification, Version 2

• fwprintf
• fwscanf
• swprintf
• swscanf
• vfwprintf
• vswprintf
• vwprintf
• wprintf (wird aber in der Manpage von wcstok(3) erwähnt...)
• wscanf

Single Unix Specification, Version 3

• vfwscanf
• vswscanf
• vwscanf

Proprietär, aber in NetBSD und glibc zu finden

• wcsdup
• wcsncasecmp
• wcscasecmp

Man beachte, dass die allermeisten Funktionen schon in SuSv2 spezifiziert sind und es als solche auch in C99 reingeschafft haben.

Tja, und da war es dann aus bei mir mit der guten Laune. Ist es tatsächlich zuviel verlangt von einem doch vergleichsweise populären Betriebssystem (gemessen an der Open-Source-Community, nicht der Gesamtheit aller Computeruser weltweit), etablierte Standards, die thematisch eigentlich genau in die Projektzielsetzung von OpenBSD fallen, umzusetzen, oder ist OpenBSD neuerdings dazu übergegangen, ein möglichst kastriertes System, das entfernt noch irgendwie an Unix erinnert, zu entwickeln? Es ist ja nicht so, dass die Komplexität der oben genannte Funktionen besonders groß wäre, immerhin gibt es davon ja fertige Implementierungen, die sogar in einer für OpenBSD akzeptablen Lizenz vorliegen (nämlich die Entwicklungen des Citrus-Projekts).

Unter solchen Voraussetzungen, dass nicht einmal 13 Jahre alte Standards aus dem C- und Unix-Umfeld umgesetzt werden, kann ich auf jeden Fall OpenBSD nicht mehr als ernstzunehmendes Unix-artiges Betriebssystem betrachten. Ich zeige kein Verständnis für Extrawürste und bewusst weggelassene Funktionalität. Solange nicht zumindest swprintf() in OpenBSD existiert, ist newsbeuter-Support für OpenBSD gestorben, explizit auch so dokumentiert, und ich kann nur jedem, der ernsthafte Open-Source-Entwicklung betreiben will, von einer angestrebten Kompatibilität mit OpenBSD abraten, weil dafür im Vergleich zu anderen System riesige Kompromisse eingegangen werden müssten.

Bisher hab ich mich ja eher zurückgehalten in der aktuellen Diskussion um Exkludisten und Relevanzkriterien (ein Überblick hier: Kris Köhntopp 1, 2, F!XMBR, Fefe, Pavel), mittlerweile ist das ganze aber schon so weit gediehen, dass ich auch mal meinen Senf dazugeben muss.

Dabei will ich mich primär überhaupt nicht mit den konkreten Ereignissen (konsequente Löschung von Artikeln und Erwähnungen der verschiedensten Themen, beispielsweise MOGiS) befassen, sondern meinen Blick auf die grundsätzlicheren Problematiken, und zwar einerseits den Relevanzbegriff, den Exkludismus an sich und die praktischen Auswirkungen des ganzen.

Der Exkludismus als solches ist eine Bewegung innerhalb der Wikipedia-Community, die aufgrund von bestimmten Kriterien entscheiden will, welche Artikel in die Wikipedia reindürfen und welche nicht. Das beliebteste Argument für eine Entscheidung gegen eine Aufnahme sind die Relevanzkriterien, ein historisch gewachsenes Dokument. Selbstdarstellung, Werbung oder ähnliches ist natürlich auch nicht erwünscht, das Lemma (vereinfacht gesagt der Name, unter dem der Artikel läuft) sollte auch einen gewissen allgemeinen Bekanntheitsgrad haben, reine "Internetbekanntheit" zählt nach Auffassung vieler Exkludisten nicht. Was hier übersehen wird: die Relevanz- und weitere Kriterien, die angelegt werden, um eine Entscheidung für oder wider einen Artikel herbeizuführen, sind auch nur Meinungen. Gebildet zwar von Leuten, die sicherlich schon länger bei Wikipedia aktiv mitarbeiten, aber daraus lässt sich schon grundsätzlich kein unumstößlicher Wahrheitsanspruch ableiten.

Auch der oft angeführte Begriff der "Bekanntheit" ist subjektiv: wer weiß denn schon alles, wer kennt jeden? Niemand ist allwissend, wer allerdings Begriffe außerhalb seines Horizonts leugnet (und derartige Gestalten gibt es genug in Löschdiskussionen), der kann unweigerlich nur Schaden anrichten. Als überspitztes Beispiel kann ich da nur die Position des Solipsisten-Wikipedianers nennen: wäre ein Solipsist konsequent, so müsste er alle Artikel außer über sich selbst löschen. Sobald es mehr als einen Solipsisten-Wikipedianer gibt, so gibt es nur noch soviele Artikel wie Solipsisten, und selbst diese sind alle gelöscht bzw. im Prozess des Gelöscht-werdens.

Aber um die Bekanntheitsdiskussion wieder auf "normalere" Bahnen zu bringen: seit gestern gibt es einen Artikel über Fefes Blog, in dem mehrfach die Bekanntheit von Felix von Leitner (aka Fefe) geleugnet wurde, weil sich diese lediglich auf eine geringe Anzahl von Onlinemedien beschränken würde. Was habe ich gelacht. Abgesehen davon, dass dieses Argument vollkommen fehl am Platz war (denn es ging um Fefes Blog, und nicht um die Person), würde man diese Kriterien an andere Personen, zu denen es Wikipedia-Artikel gibt, anwenden, dann müsste man konsequenterweise auch den Artikel zu Jimmy Wales löschen. Wer ist Jimmy Wales? Frag mal deinen Opa, deine Mutter, oder deinen Bruder, ob die wissen, wer Jimmy Wales ist. Ach, die wissen das nicht? Wie kann es dann einen Artikel über diese Person geben, wo doch nur eine sehr eingeschränkte Bekanntheit gegeben ist? Tja, Jimmy Wales hat halt eben "zufällig" die Wikipedia gegründet.

Ein oftmaliges Argument, über das man immer wieder stolpert, das man im Zusammenhang mit dem Exkludismus hört, ist, dass es in der deutschsprachigen Wikipedia schon zuwenige aktive Mitarbeiter gäbe, und man daher "schlechte" oder "irrelevante" Artikel löschen müsse, um die bestehende Arbeitskraft auf die bestehende Artikelmenge kanalisieren zu können, ist genauso einfach wie falsch. Nicht nur, dass Proponenten derartiger Irrmeinungen garnicht in den Sinn kommt, dass genau durch großzügige Löschaktionen Leute, die mitarbeiten wollen, vertrieben werden (ganz ehrlich, wer will sich in einem Projekt engagieren, mitarbeiten und sich herumstreiten müssen, wenn gerade die eigene Arbeit gelöscht worden ist?), nein, durch Löschanträge oder gar Schnelllöschanträge auf neue Artikel werden potentiell umfassendere Arbeiten an neuen Themen unterdrückt und aus ihrem Kontext gerissen, einzelnen Artikeln oder gar einer ganzen Serie davon wird die Möglichkeit genommen, sich zu entwickeln. Nein, vollkommen falsche Sichtweise: Personen, die sich in Wikipedia in Form von Artikel schreiben einbringen wollen, werden daran gehindert, genau diese Artikel in einen (für wen auch immer) akzeptablen Zustand zu bringen. Es wird also aktiv Wissen vernichtet und durch die Regeln, unter welchen Umständen ein bereits gelöschter Artikel zu einem Lemma nochmal neu erstellt werden darf, wird auch verhindert, dass (außerhalb der Wikipedia bestehendes) Wissen in die Wikipedia integriert, vernetzt und damit in ein größeren Kontext gestellt wird. Das ist die traurige Realität, und entspricht sicherlich nicht dem Grundgedanken der Wikipedia, den Jimmy Wales predigt:

Aber Wikipedia ist mehr als nur eine Internetseite. Wir haben ein gemeinsames Motiv: Stell dir eine Welt vor, in der jeder Mensch auf der Erde freien Zugang zum gesamten menschlichen Wissen hat. Das ist unsere Verpflichtung.

(Jimmy Wales - Quelle)

Das Wissen der Welt zu sammeln heißt, auch solches in die Wikipedia mitaufzunehmen, das Kriterien, die einem scheinbaren Konsens (scheinbarer Konsens nur deswegen, weil es der Konsens einer Gruppe von Personen ist, die zu einem bestimmten Zeitpunkt in der Wikipedia aktiv waren) nicht entsprechen. Das ist meine Überzeugung.

Und überhaupt, das Löschen. Speicherplatz ist billig, Speicherplatz ist kein Problem für die Wikipedia, denn: Wenn ein Artikel in der Wikipedia "gelöscht" ist, so ist der Inhalt nicht etwa tatsächlich gelöscht, sondern lediglich für alle Personen außer Admins unsichtbar. Besonders perfide, hier wird also bereits in der Wikipedia gesammeltes Wissen bewusst zurückgehalten, Willkür auf rein technischer Ebene.

Naja, man wird ja sehen, wie sich die aktuelle Debatte entwickeln wird. Zumindest jetzt schon sieht man, wie immer mehr Leute von einer aktiven Mitarbeit an der deutschsprachigen Wikipedia Abstand nehmen, und das vollkommen zurecht. Ein zu notierender Termin ist auf jeden Fall auch die hier angekündigte Veranstaltung am 5.11. um 18:00 Uhr in den Räumen von Wikimedia Deutschland in Berlin (Kris Köhntopp vermutet, wo das sein wird).

Und zu guter letzt noch ein kleiner Rant über MediaWiki, die Wiki-Software, die Wikipedia eingesetzt wird: poah, ist die Software schlecht! Dass sämtliche Diskussionen ausschließlich im MediaWiki ausgefochten werden, macht es absolut unmöglich, Diskussionen auch nur irgendwie sinnvoll zu verfolgen und zu überblicken. Auch aus Versionsverwaltungssicht einfach nur ein Graus: exklusives Locking will man ja schon mal prinzipiell nicht (die Folge wäre ein einziger Denial of Service auf die Editierfunktion), aber dann sollte ein Mergen von Änderungen sowie ein sinnvolles Interface zum Beheben von Mergekonflikten vorhanden sein. Allein schon das ist ein großer Faktor, der die praktische Benutzbarkeit von Wikipedia einschränkt und eine aktive Teilnahme an kontroversen Thematiken fast schon verunmöglicht.

Und ganz zum Abschluss noch Grüße an die Wikipedia-Kritiker A. und C., die schon länger als ich eine kritische Sichtweise zur deutschen Wikipedia und allen Dingen, die da falsch laufen eingenommen haben, und von denen ich ein paar Argumente schamlos abgekupfert habe.

Mittlerweile gibt es auf southpark.de im Player einen Button "watch in english". Zwar immer noch nicht optimal, aber schon eine sehr große Verbesserung. Double thumbs-up!

Mit großem Entsetzen musste ich gestern feststellen, dass die vormals wunderbare Seite southparkstudios.com nicht mehr von Deutschland aus erreichbar ist. Als Begründung wird angegeben, dass die auf der Seite gezeigten Southpark-Folgen aus Copyright- und anderen rechtlichen Gründen außerhalb der USA nicht verfügbar sind. Als "tolle" Alternative hat man jetzt southpark.de. Da kann man sich alle in Deutschland bisher ausgestrahlten Folgen ansehen. Auf Deutsch. Ausschließlich auf Deutsch. Die deutsche Synchronisation ist absolut unerträglich. Warum wird Southpark-Fans, die die Serie gerne im englischen Originalton sehen würden, so auf den Kopf gesch***** vor den Kopf gestoßen? Wieso sollte ich eigentlich noch auf einer offiziellen Southpark-Seite herumklicken, wenn es auch Seiten wie xepisodes.com gibt?

Hey, digg.com, yes, you! Your webserver just sucks. Have you ever found the time to read the relevant HTTP-related RFCs, like 1945 or 2616? I don't think so, otherwise you'd know that the User-Agent request header is not mandatory. Recommended, but definitely not mandatory. So why in hell's name does your webserver simply close the connection when sending an HTTP request without User-Agent header, and why does it keep the connection open without any response when I send a request without User-Agent header but with a Connection: keep-alive header? I've never seen an HTTP server implementation that is broken in a more braindead way. If you don't like clients w/o User-Agent header, why couldn't you at least reply with a nice "HTTP/1.1 5xx Fuck You"? Absolutely ridiculous.

Ein Rant über meine Bank ist notwendig. Fürs Online-Banking dort waren zuerst TANs, dann indizierte TANs (iTAN) im Einsatz. Ich halte die indizierten TANs in Kombination mit Username und Passwort für ausreichend sicher, insbesondere, weil die iTAN-Liste die Merkmale eines Codebuchs aufweist. Noch dazu ist der Übermittlungsweg der iTAN-Liste aufgrund der speziellen Verpackung (undurchsichtiges, vor Durchschein-Angriffen mit einem S/W-Zufallsmuster geschütztes Kuvert, in die iTAN-Liste de facto nicht mehr knitterfrei zurück eingeführt werden kann) hinreichend vertrauenswürdig.

Vor ein paar Monaten wollten die mir doch allerdings "TAC-SMS" (Wikipedia nennt es mobile TAN [mTAN]) anbieten. Das funktioniert dann so, dass man übers Online-Banking-Interface ein SMS an sein Handy anfordern kann, worüber dann ein 5 Minuten lang gültiger Code übermittelt wird. Abgesehen davon, dass als Übertragungsweg ein streckenweise unverschlüsselter und grundsätzlich als kompromittiert geltender Kanal verwendet wird, so steht als Angriffsvektor immer noch das Handy selbst da: einerseits könnte es gestohlen werden, andererseits könnte auf dem Handy eingeschleuste Schadsoftware das SMS direkt abgreifen. Das vormals physische Codebuch wird bei mTAN damit auf deutlich schwieriger auditbare Medien als bei TAN/iTAN verlagert. So weit, so schlecht.

Wirklich schlimm wird das ganze allerdings durch den Umstand, dass seit neuestem Überweisungen von Beträgen mehr als EUR 1000,- via iTAN bei der Sparkasse nicht mehr möglich sind. Das default sind übrigens EUR 300,- (damit könnte ich nicht mal meine Miete zahlen), und ich musste intervenieren, um das Limit hochgesetzt zu bekommen.

Ich frage mich echt, wer bei der Sparkasse für das threat modeling zuständig ist. Wahrscheinlich der gleiche Schlag Mensch, der auch die Vorteile von Wahlcomputern preisen würde. Oder doch jemand, der in einem Deployment von mTAN statt TAN/iTAN ein erhebliches Einsparungspotential sieht? Eigentlich will ich es garnicht wissen.

Poah, wenn ich sowas lese, dann muss ich kotzen:

Stallman sagte, auch der Kernel enthalte nicht freie Bestandteile. Torvalds persönlich bezeichnete der GNU-Gründer als "einen Studenten, der einen Kernel geschrieben hat".Stallman wirft Torvalds vor, nicht für freie Software einzustehen sondern vielmehr den Spaß am Programmieren im Vordergrund zu sehen.

Ich sage nur: was RMS mittlerweile so von sich gibt, ist völlig überbewertet. Wenn RMS Linus Torvalds vorwirft, den Spaß an der Programmierung hochzustellen, dann ist das im Grunde genommen der Vorwurf, dass Linus Torvalds ein Hacker (im ursprünglichen Sinne) ist.

Meiner Meinung nach zeigt das doch wieder einmal, wie verbohrt RMS mittlerweile "seine" Ideologie bewirbt. Auch nion meint, dass RMS nur noch zu seinesgleichen predigt. Und dann noch sowas:

Vor allem kommt es laut Stallman darauf an, dass Schulen "allein freie Software unterrichten und einsetzen". Damit könnten sie zum einen Geld sparen. Frei heiße zwar nicht unbedingt kostenlos. Aber gerade für Ausbildungsstätten sei die Freiheit wichtig, "Programme weiter zu verbreiten".

Ich sage: man darf Fundamentalisten wie RMS nicht die Deutungshoheit über den Freiheitsbegriff kampflos überlassen.

Der Richtungsstreit zum Freiheitsbegriff im Kontext Software führt ja im wesentlichen in zwei Richtungen, und zwar einerseits die individuelle Freiheit, und andererseits die kollektive Freiheit. Während GNU-Fundis wie RMS ausschließlich kollektive Freiheit fordern, und dabei individuelle Freiheiten ziemlich zugrunde richten, ist die Gegenbewegung um keinen Deut besser, nämlich die BSD-Fundis, die es zwar OK finden, dass ihre Arbeit von kommerziellen Firmen en masse gerippt wird, aber sich daran stößt, wenn sich BSD-Sourcecode in GPL-lizenzierter Software wiederfindet: individuelle Freiheit über alles, aber kollektive Freiheit wird aktiv bekämpft. Ein dringend nötiger Ausgleich zwischen den beiden fundamentalistischen Position ist dringendst notwendig, aber leider nicht in Sicht. Klar ist aber, dass diese Art von Fundamentalismus in einem Themenkomplex wie Softwarelizenzierung mittel- bis langfristig äußerst schädlich ist.

Und zu guter Letzt möchte ich noch betonen: zur wahren Freiheit gehört auch dazu, die Freiheit zu haben, zwischen Freier Software/Open Source und proprietärer Software wählen zu können.

Der neueste Hype ist Arc, ein Lisp-Dialekt. Und naja, was soll man dazu sagen?

I went to a talk last summer by Guido van Rossum about Python, and he seemed to have spent most of the preceding year switching from one representation of characters to another. I never want to blow a year dealing with characters. Why did Guido have to? Because he had to think about compatibility. But though it seems benevolent to worry about breaking existing code, ultimately there's a cost: it means you spend a year dealing with character sets instead of making the language more powerful.

Which is why, incidentally, Arc only supports Ascii.

Die allergrößte Mehrzahl aller natürlichen Sprachen lassen sich nicht mit dem Zeichensatz, den ASCII bietet, notieren. Damit schließt Paul Graham, der Autor von Arc, schon einmal von vornherein jegliche Lokalisierungs- und Internationalisierungsbemühungen aus. Wer Lisp verwenden will, der greife lieber zu CLisp, die denken nämlich an I18N/L10N. Lokalisierte Software für wachsende Zukunftsmärkte wie Indien oder China lässt sich mit Arc nämlich nicht entwickeln (naja, schon, aber wer will schon manuellen Lisp-Code für diverse Character Encodings schreiben?).

Enjoy your FAIL, Paul.

...als Beispiel für schlechten Code (das hier ist aus local-fetch.c):Warum muss ich bloß ca. 5 Sekunden grep(1)en, um ein ideales Codebeispiel zu finden, wie man mit Strings, Pfaden und User Input nicht umgeht in C?

Update: weil gefragt wurde, wie's richtig geht, hier noch die Auflösung:Das ist nicht nur sicherer, sondern auch kompakter und lesbarer. Nein, ich werde keinen Patch submitten.

Weil ich gerade einen herzlich sinnlosen Patch für das newsbeuter-Makefile gekriegt hab, der pkg-config dazu einsetzt, diverse Libraries zu finden, hab ich im Issue Tracker gleich mal ordentlich gerantet. Und eigentlich sollte dieser pkg-config-Rant auch meinen werten Lesern hier nicht vorenthalten werden:

Rejected.
(a) Mentioned libraries are installed in system-wide directories by definition.
(b) When a user is capable installing it outside of the usual system-wide directories, he's also capable of adapting the Makefile accordingly.
(c) IMHO, it's very unlikely that somebody installs the library somewhere outside of a system-wide directory, but then takes care that the according .pc files are installed when pkg-config is searching for it.

A great example for the utter failure of pkg-config is how it fails to work with libraries that are installed via Fink on Mac OS X. Fink installs all its software under /sw, which is definitely not one of the "usual" prefixes such as /usr and /usr/local. And of course, the pkg-config that is delivered with Mac OS X fails to find any of the .pc file that are installed under /sw. When using the pkg-config that is delivered with Fink, the .pc files that are installed under /usr aren't found. In theory, pkg-config is great, but in practise, it's absolutely awful and IMHO less reliable than not using any semi-magic auto-detection mechanism.

Additionally, it depends on glib2, and I'm not going to endorse the installation of a plethora of bloated software that is of no direct use to users of newsbeuter.

Wenn man in einem Online-Config-Interface alle Mehrwertnummern sperrt, dann könnte man meinen, dass dann alle Mehrwertnummern gesperrt sind. Dem ist nicht so, zumindest bei ONE. Im Zusammenhang mit den hier bereits erwähnten Wap-Push-Messages sind ein paar unschöne Rechnungspunkte auf meiner Einzelverbindungsübersicht fürs laufende Monat erschienen, obwohl ich schon kurz nach Abschluss des Vertrags sämtliche Mehrwertnummern gesperrt hatte. Besonders toll war dann auch, dass ich mir an der ONE-Kunden-Hotline anhören durfte, dass auf deren Interface nichts zu sehen war, dass ich irgendeine Sperrung vorgenommen hätte, und dass, falls ich tatsächlich die Sperrung durchgeführt hätte, ich es wahrscheinlich "falsch" gemacht hätte. Hallo?! Geht's noch? Das Interface sieht so aus:

Und hinter dem "Ändern"-Button hängt nichts anderes als die Auswahl "Aktiviert" bzw. "Gesperrt". Was sollte man da falsch machen? Auf jeden Fall hab ich ONE dann angewiesen, dass doch zu sperren. Und jetzt kann man's nicht mal über die Website reaktivieren. Bei der Mehrwertnummernsperre scheint ONE also ein echtes Problem zu haben. Auf jeden Fall, sobald ich die Rechnung für August erhalte, werde ich da einen schönen Einspruch dagegen machen, und ONE wird sich rechtfertigen müssen, warum eine Sperrung keine Sperrung ist.

Ich bin derzeit dabei, ein wenig competitive analysis im Bereich RSS-Feedreader durchzuführen (man muss sich ja mit knackigen Ideen für neue newsbeuter-Features versorgen), und bin im Zuge dessen auf die Idee gekommen, Synchronisations-Support mit diversen Online-RSS-Readern umzusetzen. Etliche Online-RSS-Reader implementieren eine mehr oder weniger komplexe API (auf HTTP-Basis), um eine gewisse Synchronisation durchzuführen. Die größeren "Player" in dem Bereich sind Bloglines, NewsGator und Google Reader.

Nun ja, der Bloglines-Support ist schon implementiert (und funktioniert ganz OK, soweit ich nach den ersten Tests sagen kann), Google Reader hat das Problem, keine öffentliche API-Doku zu haben (es gibt lediglich eine reverse-engineerte), und NewsGator... ja, NewsGator. Die haben eine ziemlich komplexe API. Gut, das ist kein Problem, ganz im Gegenteil, damit könnte man nette Sachen machen. Allerdings: mit der Benützung der API verbunden ist das Einverständnis mit diesem langen License Agreement durch den Entwickler, und man braucht einen API Product Key, bei dessen Beantragung angeben muss, ob das Produkt "commercial" oder "non-commercial" ist. Das License Agreement ist ja schon mal toll, wenn ich nicht mit allem einverstanden bin, darf ich die API nicht einmal implementieren, außerdem muss man bei "non-commercial use" überall, wo als Backend die NewsGator API verwenden wird, das NewsGator-Logo anzeigen, und bei "commercial use" ist sowieso ein License Fee fällig. Da ich in meiner Lizenzierung von newsbeuter aber keine Aussagen über die Verwendung mache (ist mir doch egal, ob da jemand mit newsbeuter Geld verdient, ist sowieso eher unwahrscheinlich), sehe ich mich außerstande, mich auf eine bestimmte Verwendungsart festzulegen, und den jeweiligen Bedingungen (Logo bzw. License Fee) kann ich sowieso nicht folgen. Außerdem ist in dem License Agreement eine Art NDA verpackt. Damit sind die Lizenzbedingungen absolut inakzeptabel, weswegen ich auf keinen Fall jemals NewsGator-Support implementieren werde. Sollte jemand noch andere Online-Reader mit öffentlicher API und weniger restriktiven Nutzungsbedingungen kennen, die auch unterstützenswert sein könnten, bitte ich um freundliche Eingaben in den Kommentaren.

Sicher ist das schon einigen Leuten aufgefallen, dass Videos zu kontroversen Themen der heutigen Zeit, wie z.B. 9/11, Israel, Libanonkrieg, Iran, Irakkrieg, Türkei oder die USA ansich, die entsprechend weit oben gereiht sind bei Youtube, von tausenden von Kommentaren ueberschwemmt, wo sich jede Menge Leute mit variierender Ausdrucksfähigkeit und Rechtschreibkenntnis gegenseitig mit Einzeilern niederflamen. Revisionisten haben in so einer Umgebung natürlich die besten Möglichkeiten, sich auszubreiten. Und so auch bei einem Video auf Youtube, das ich raufgeladen habe, und das einen Ausschnitt der faschistischen Wochenschau zu den Februarkämpfen 1934 in Linz zeigt (siehe Wikipedia zu den Hintergründen). Gestern hat da ein User mit scheinbarem Bundesheer-Hintergrund doch tatsächlich so Sachen wie "Es lebe die christlichsoziale Partei!" und "Die Christlichsozialen waren die einzigen in Österreich die sich gegen den Nationalsozialismus stellten!" gepostet. Letzteres stimmt natürlich, im Kontext vor 1938, weil die Christlichsozialen die einzigen waren, die das noch machen konnten. Die Opposition steckte ja schon in den austrofaschistischen Anhaltelagern. 1938, ja, da war das was anderes. Da hat ein Christlichsozialer (bzw. ein Mitglied der Nachfolgeorganisation) das Berchtesgadener Abkommen unterschrieben.

Aber die Kommentare zeigen auf jeden Fall eindeutig, wes Geistes Kind diese Person ist. In der Öffentlichkeit würde sich heutzutage sowas niemand mehr trauen zu sagen, da wird die die Gesinnung höchstens durch ein Dollfuß-Bild hier und da zur Schau gestellt. Kennen wir ja aus dem ÖVP-Parlamentsklub. Aber im Internet, da traut sich jeder Internet-Parteikader und jeder Wohnzimmer-General, seine Meinung, und sei sie noch so absurd oder selbstentlarvend, zu postulieren, im Schutze der Pseudonymität. Nicht, dass das per se was schlechtes wäre (ich sollte mal über meine Leidenschaft zu Flames und Trolling in der neoliberalen Blogszene bloggen [die sich in Österreich als "liberal" gibt und gleichzeitig sozialdarwinistische Thesen postuliert, aber das nur nebenbei]), nur gerade in diesem Fall (der Austrofaschismus war ja nur das zweitschlimmste politische System nach der Nazi-Herrschaft, deswegen wird es überhaupt nicht aufgearbeitet) zeigt sich, welche Ideologien in den Köpfen der Menschen noch herumschwirren. Und natürlich werden diese Ideologien in den Youtube-Kommentaren ausgelebt, neben den 9/11-Verschwörungstheoretikern, den Israelverteidigern bzw. -gegnern, den Irankrieg-Befürworter bzw. -Gegnern, den türkischen Nationalisten bzw. Islamisten, und den Verteidigern der US-amerikanischen Politik bzw. deren Gegnern. Ohne dass das eigentlich irgendeinen Sinn hätte, weil eine sinnvolle Diskussion kommt in diesem völlig ungeeigneten Medium (Threading, anyone? Usenet hat halt doch noch seine Qualitäten, nur das kann der 08/15-Youtube-Klicker nicht bedienen) nicht wirklich möglich ist.

Ein paar Alternativen zum derzeitigen make-basierten Buildsystem bei newsbeuter evaluiert. SCons und CMake. Frustriert wieder aufgegeben, weil sich die Anforderungen, die ich habe, entweder mit viel Fummelei oder gleich gar nicht umsetzbar sind. Mit SCons hab ich durch etwas umstrukturieren (gemeinsam genutzte Objekte musste ich in eine statische Lib zusammenfassen, sonst will SCons da garnichts compilieren) den Buildprozess so hingebracht, wie ich wollte, und CMake... naja, sagen wir mal so, man merkt an der Qualitaet der CMake-Dokumentation, dass es auch ein CMake-Buch gibt.

Was sind überhaupt meine Anforderungen? Es sollen zwei Binaries erzeugt werden, aus C++-Sourcecode, wobei sich beide Binaries eine gewisse Anzahl von C++-Sourcefiles teilen. Zusaetzlich gibt es noch regulaere Header-Files sowie .stfl-Files, die durch ein Perl-Preprocessor-Script in Header-Files umgewandelt werden. Die Umsetzung als Makefile ist halbwegs kompakt, und noch gut wartbar.

Wie schon oben beschrieben, der vielversprechendste Kandidat schien SCons zu sein, bis ich mir dann genauer angeschaut habe, wie man die Installation von Dateien umsetzen soll. Das ist, mit Verlaub, der hirnrissigste Schwachsinn, den ich jemals gesehen habe. Die SCons-Leute haben eindeutig die falschen Drogen konsumiert, wie sie das designed haben. Nein, das will ich nicht benutzen.

Warum tu ich mir das ueberhaupt an? Weil ich vor dem eigentlichen Compile auch ein paar Details ueber die Zielplattform rausfinden will (und zwar mehr als nur triviales "ist Header foobar.h vorhanden" und "ist Library libquux eh da"), und mit reinen Makefiles ist das ein einziger PITA. Tja, mit autoconf waeren meine Anforderungen hinreichend gut umsetzbar, weil das Makefile ohne viel Aufwand portierbar waere, aber das will ich mir selbst nicht antun. autoconf ist zwar gut customizable, aber ein einziger Haufen Dreck, vor allem weil es dann zu Zustaenden wie den folgenden fuehren wuerde:
-rwxr-xr-x 1 ak ak 43K 2007-04-02 13:03 config.guess
-rwxr-xr-x 1 ak ak 15K 2007-04-02 13:03 config.rpath
-rwxr-xr-x 1 ak ak 28K 2007-04-02 13:06 config.status
-rwxr-xr-x 1 ak ak 31K 2007-04-02 13:02 config.sub
-rwxr-xr-x 1 ak ak 156K 2007-04-02 13:05 configure
-rwxr-xr-x 1 ak ak 9.1K 2007-04-02 12:43 install-sh
Ja, richtig gesehen, das sind knapp 280 kB Skripte, die da zusaetzlich mitgeshipped werden wuerden, fuer ein paar simple Tests.

Und eines kann ich auch ausschließen: ich werde sicher kein zusaetzliches Build-Tool entwickeln, das kann nur in die Hose gehen. Tja, alles scheisse eben.

Nachdem das Ranten über GNU so schön ist, hier noch ein kleiner Nachschlag. Wieder fast jeder, der schon mal Software unter Linux selbst compiled hat, weiß, muss man vor dem Übersetzen meist noch ./configure aufrufen, welches dann ein paar systemspezifische Konfigurationsinformationen sammelt und ein Makefile generiert.

Zum Erstellen dieses configure-Skripts gibt es ein Tool namens autoconf. Dieses generiert aus einem configure.in bzw. configure.ac File das configure-Skript. Das configure.ac wiederum kann man sich aus dem bestehenden Sourcetree generieren lassen und dann händisch anpassen. Das Makefile, das man dann zum Compilieren benötigt, wird übrigens vom configure-Skript i.A. aus dem Makefile.in erzeugt, wobei hierbei Platzhalter durch die entsprechenden ermittelten bzw. gesetzten Werte (./configure lässt sich ja relativ gut durch Commandline-Switches steuern) ersetzt werde. Makefile.in's schreiben sich ähnlich wie Makefiles. Und weil das Schreiben von Makefile.in's sooo schwer ist, gibt es auch gleich noch ein weiteres Tool, automake, mit dem man sich das Makefile.in aus einem Makefile.am erzeugen lassen kann.

Durch einen jahrelangen Reifungsprozess sind autoconf und automake schon so gut integriert, dass sie fast eine Symbiose bilden. Diese Symbiose ist so gut, dass es vom GNU-Projekt keine Dokumentation gibt, wie man autoconf ohne automake verwendet. Das heisst, jeder enthusiastische Programmierer, der auf die Vorteile von autoconf zurückgreifen will, und sich das selbst anhand der Doku aneignet, wird auch automake verwenden. Am Ende der Integration von autoconf und automake ins eigene Sourcepaket bleiben dann ein ca. 200 kB grosses configure-Skript und ein 50 kB grosses Makefile.in übrig, sowie noch 50 - 100 kB andere Dateien wie z.B. diverse Helper-Shellskripte. Das ist natürlich sehr toll, wenn das eigene, selbstgeschriebene Tool aus vielleicht 15 kB Sourcen besteht.

Aber trotzdem gibt es Mittel und Wege, um ohne automake auszukommen, was die Gesamtgröße der generierten Dateien um einiges herabsetzt. Wie das im Detail geht, wäre jetzt zuviel des guten, jedoch nur ein kurzer Tipp: wer Makefiles schreiben kann, und /usr/local durch _prefix und gcc durch _CC ersetzen kann, der kann Makefile.in's schreiben, und braucht kein automake.

Hier noch mal die Erklärung: autoconf sorgt für das configure-Skript, das Systemkonfiguration sammelt und das Makefile erzeugt, und automake sorgt für das Makefile.in-Template, sodass der Programmierer sich um weniger Makefile-Details kümmern muss (muhahahaha). Eigentlich eine gute Trennung. Theoretisch. Wie sieht es praktisch aus? Nun, das Dokumentationsproblem habe ich schon erwähnt, aber etwas wesentlich perfideres hab ich heute wieder mal entdecken müssen: autoconf ist ja m4-basiert, und bringt einige fertige m4-Makros zum Testen auf bestimmte Konfigurationen mit. Allerdings gibt es noch wesentlich mehr Makros. Zum Beispiel bei automake. Bei automake sind wirklich jede Menge m4-Makros dabei, die wesentlich mehr können, und die einfach eingebunden werden können. Welche Möglichkeiten hat Joe Average Programmer hier? Entweder er kopiert die m4-Makros aus dem automake-Paket in seinen eigenen Sourcetree, oder aber integriert einfach automake in sein eigenes Buildsystem.

Warum GNU diese Makros nicht zu autoconf dazugepackt hat? Nun, das weiß nur Gott ("Gott? welcher Gott?"). Auf jeden Fall haben diese Beobachtungen bei mir den schalen Nachgeschmack hinterlassen, GNU will möglichst viele Programmierer mit autoconf und automake "zwangsbeglücken". Mittlerweile ist es ja fast nicht mehr möglich, ohne das Konfigurieren des Sourcetrees auf Systemeigenheiten noch portable Programme zu schreiben, die "out of the box" unter einem Allerwelts-Unix wie Linux, *BSD und Solaris compilieren und linken. GNU hat sicherlich seines dazu beigetragen, und bringt gleichzeitig ein "Wundermittel" mit, das halt zu 300 kB Scheisse in jedem Sourcepaket führt. Leider sind autoconf und automake als de-facto-Standard etabliert, andere Buildsysteme dagegen finden kaum Beachtung oder Einsatz.