Introduction
In the beginning, there was char. It could hold an ASCII character and then some, and that was good enough for everybody. But later, the need for internationalization (i18n) and localization (l10n) came up, and char wasn't enough anymore to store all fancy characters. Thus, multi-byte character encodings were conceived, where two or more chars represented a single character. Additionally, a vast set of incompatible character sets and encodings had been established, most of them incompatible to each other. Thus, a solution had to be found to unify this mess, and the solution was wchar_t, a data type big enough to hold any character (or so it was thought).

Multi-byte and wide-character strings
To connect the harsh reality of weird multi-byte character encodings and the ideal world of abstract representations of characters, a number of interfaces to convert between these two was developed. The most simple ones are mbtowc() (to convert a multi-byte character to a wchar_t) and wctomb() (to convert a wchar_t to a multi-byte character). The multi-byte character encoding is assumed to be the current locale's one.

But even those two functions bear a huge problem: they are not thread-safe. The Single Unix Specification version 3 mentions this for wctomb, but not for mbtowc, while glibc documentation mentions this for both. The solution? Use the equivalent thread-safe functions mbrtowc and wcrtomb. Both of these functions keep their state in a mbstate_t variable provided by the caller. In practice, most functions related to the conversion of multi-byte strings to wide-character strings and vice versa are available in two versions: one that is simpler (one function argument less), but not thread-safe or reentrant, and one that requires a bit more work for a programmer (i.e. declare mbstate_t variable, initialize it and use the functions that use this variable) but is thread-safe.

Coping with different character sets
To convert different character sets/encoding between each other, Unix provides another API, named iconv(). It provides the user with the ability to convert text from any character set/encoding to any other character set/encoding. But this approach has a terrible disadvantage: in order to convert text of any encoding to multi-byte strings, the only standard way that Unix provides is to use iconv() to convert the text to the current locale's character set and then convert this to a wide-character string.

Assume we have a string encoded in Shift_JIS, a common character encoding for the Japanese language, and ISO-8859-1 (Latin 1) as the current locale's character set: we'd first need to convert the Shift_JIS text to ISO-8859-1, a step that is most likely lossy (unless only the ASCII-compatible part of Shift_JIS is used), and only then we can use to mb*towc* functions to convert it to a wide-character string. So, as we can see, there is no standard solution for this problem.

How is this solved in practice? In glibc (and GNU libiconv), the iconv() implementation allows the use of a pseudo character encoding named "WCHAR_T" that represents wide-character strings of the local platform. But this solution is messy, as the programmer who uses iconv() has to manually cast char * to wchar_t * and vice versa. The problem with this solution is that support for the WCHAR_T encoding is not guaranteed by any standard, and is totally implementation-specific. For example, while it is available on Linux/glibc, FreeBSD and Mac OS X, it is not available on NetBSD, and thus not an option for truly portable programming.

Mac OS X (besides providing iconv()) follows a different approach: in addition to the functions that by default always use the current locale's character encoding, a set of functions to work with any other locale is provided, all to be found under the umbrella of the xlocale.h header. The problem with this solution is that it's not portable, either, and practically only available on Mac OS X.

Alternatives
Plan 9 was the first operating system that adapted UTF-8 as its only character encoding. In fact, UTF-8 was conceived by two principal Plan 9 developers, Rob Pike and Ken Thompson, in an effort to make Plan 9 Unicode-compatible while retaining full compatibility to ASCII. Plan 9's API to cope with UTF-8 and Unicode is now available as libutf. While it doesn't solve the character encoding conversion issue described above, and assumes everything to be UTF-8, it provides a clean and minimalistic interface to handle Unicode text. Unfortunately, due to the decision to represent a Rune (i.e. a Unicode character) as unsigned short (16 bit on most platforms), libutf is restricted to handling Unicode characters of the Unicode Basic Multilingual Plane (BMP) only.

Another alternative is ICU by IBM, a seemingly grand unified solution for all topics related to i18n, l10n and m17n. AFAIK, it solves all of the issues mentioned above, but on the other side, is perceived as a big, bloated mess. And while its developers aim for great portability, it is non-standard and has to be integrated manually on the respective target platform(s).

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.

In letzter Zeit, vor allem nach Anschaffung eines eigenen Filmscanners, habe ich wieder angefangen, Schwarz-Weiß-Film selbst zu entwickeln. Da liest man immer wieder nach, was denn andere so schreiben über das Entwickeln von Film, und jedes Mal, wenn ich ein neues, anderes Tutorial finde, schlage ich die Hände über dem Kopf zusammen. Egal, als wie einfach und "für Einsteiger" so Beschreibungen bezeichnet werden, es findet sich immer wieder unnötiger Mist da drinnen, der insbesondere für Einsteiger und Anfänger viel zu verwirrend ist oder nur dazu dienen soll, den Verkauf von unnötigem Scheiß zumindest ein bisschen anzukurbeln. Meine Beobachtungen waren die Motivation, diesen Text mit meinen Gedanken und Tipps zum diesem Thema zusammenzuschreiben, basierend auf meinen Erfahrungen. Ich behaupte nicht, von der Materie was zu verstehen, aber immerhin beherrsche ich es gut genug, um meine eigenen Filme selbst zu entwickeln. Achja: durch den ganzen Text zieht sich eine "FUCK THAT SHIT!"-Einstellung, auf Genauigkeit und Dogmen wird geschissen.

Der Anfang
Also, man hat also einen Schwarz-Weiß-Film belichtet (ich kann hier nur von 120er-Rollfilm sprechen, 135er interessiert mich eher wenig). Man will den Film entwickeln, früher hätte man auch noch Abzüge davon gemacht, heutzutage bietet es sich eher eine Digitalisierung an, letztendlich will man die Bilder ja sowieso im Computer haben.

Die Entwicklerdose
Zum Entwickeln benötigt man zuerst ein lichtdichtes Gefäß, eine Entwicklerdose, bei der man den Film in eine Spule einwickeln kann. So Entwicklerdosen gibt's um EUR 20 bis 30, und sind so flexibel, dass man 135er- und 120er-Film darin entwickeln kann. Das Einspulen ist der einzige Schritt, wo man tatsächlich einen vollständig abgedunkelten Raum braucht. Eine Anleitung, wie das Einspulen geht, liegt bei, und selbst ich mit meinen halben Wurstfingern habe das bisher immer noch geschafft. Als abgedunkelten Raum verwende ich meine fensterlose Toilette, die nicht lichtdichten Schlitze decke ich mit Handtüchern ab. Das hat bisher noch immer funktioniert. Nach dem Einspulen die Dose schließen und fertig.

Das Entwickeln
Am einfachsten ist es, man besorgt sich einen Entwickler wie Rodinal (bzw. Entwickler "nach Agfa-Formel") und verdünnt die entsprechend der Anleitung mit handwarmem Wasser. Die genaue Wassertemperatur ist nicht wichtig, wenn man Leitungswasser verwendet, sollte man es so einstellen, dass es sich auf der Haut weder warm noch kalt anfühlt. Wer's genauer haben will, lagert einfach destilliertes Wasser in einem Raum, in dem ein Thermometer hängt, bei mir ist das z.B. das Badezimmer, das relativ konstant 21°C hat. Destilliertes Wasser hat noch andere Vorteile, dazu später mehr. Den verdünnten Entwickler füllt man in die Entwicklerdose, schließt die und folgt den Entwicklungsanweisungen, die sich auf der Entwicklerverpackung finden (z.B. "die erste Minute ständig kippen, danach alle 30 Sekunden"). Die Gesamtentwicklungsdauer für den passenden Film und die gewählte Entwicklerverdünnung kann man z.B. mit der Timer-Funktion von seinem Handy messen, danach Entwickler abgießen.

Das Stoppen
Stoppflüssigkeit ist Bullshit. Mit jedem Entwickler, mit dem ich bisher gearbeitet habe (Rodinal, und dann noch irgendein Auflöspulver von Ilford), hat es vollkommen genügt, zum Stoppen Wasser zu verwenden. Einfach ein paar Mal hintereinander Wasser einfüllen und wieder ausgießen, um die Entwicklerreste wegzuspülen.

Das Fixieren
Die Fixierflüssigkeit wird ähnlich wie der Entwickler zubereitet (die Verdünnungsverhältnisse und die empfohlenen Fixierzeiten stehen auch wieder auf der Verpackung), genauso eingefüllt und es wird analog gekippt und gewartet, dann ausgegossen.

Das Endwässern
Genauso wie das Stoppen mit Wasser, nur länger, um die Reste vom Fixierer zu entfernen.

Das Aufhängen und Trocknen
Normalerweise wird jetzt noch empfohlen, das ganze mit Netzflüssigkeit zu behandeln, damit das Wasser besser abrinnt. Das ist Bullshit. Ich hatte selbst mit dem relativ kalkhaltigen Berliner Wasser noch keine Probleme von Kalkflecken auf Film, wer ganz sicher gehen will, kann auch einfach als letzten Durchgang bei der Endwässerung destilliertes Wasser verwenden. Nach dieser (optionalen) Behandlung einfach den Film aus der Entwicklerdose nehmen, mit Wäscheklammern aufhängen (auch unten als Gegengewichte, damit sich der Film nicht einrollt und Wasser ordentlich abtropfen kann) und ein paar Stunden warten, bis der Film getrocknet ist. Dann den Film schneiden und einscannen, und fertig ist man.

Das Material
Hier ein paar Empfehlungen von Material, mit dem ich bisher gute Erfahrungen gemacht hab.
Entwicklerdose: dieses Modell bei Foto Impex genügt für 135er- und 120er-Film.
Entwickler: Rodinal ist in Ordnung. Ich verwende den "R09 One Shot", wie ihn Monochrom verkauft.
Fixierer: ich verwende derzeit Silberthio ph5, wie ihn Monochrom verkauft, vorher hatte ich den Ilford Rapid Fixer im Einsatz. Beide funktionieren.
Film: Ilford HP5, Kodak T-MAX 100 und 400 sind gut, wobei ich generell das Trägermaterial von Kodak etwas dünn finde, was das Handling beim Einscannen ein bisschen erschwert. Explizit abraten kann ich nur von den Fomapan-Film, die haben ein derartig grobes Korn, dass es zum Speiben ist. Die Filme sind nicht mal die wenigen Euro, die sie kosten, wert, höchstens als Experimentierfilm in Lochkameras o.ä.

Zusammenfassung
Letztendlich ist das Entwickeln von Schwarz-Weiß-Film deutlich leichter als vielfach nachzulesen, sofern man nicht dem Wahn verfällt, superexakt zu arbeiten. Schwarz-Weiß-Film hat sowieso soviel Spielraum, dass dies garnicht notwendig ist, und eigentlich nur dem Spaß verdirbt. Wen's interessiert, einfach ausprobieren. Für ganz Experimentierfreudige kann ich statt dem fertigen Entwickler was "selbstgepantschtes" empfehlen, und zwar Caffenol, das sind auf einen halben Liter Wasser acht Teelöffel Instantkaffee und zwei Teelöffel Soda (Natriumcarbonat), mit einer Entwicklungszeit von etwa 25 bis 30 Minuten.

synflood.at funktioniert wieder, inklusive der dazugehörigen Email-Adressen. Die Migration der Domain zu meinem Arbeitgeber war schwieriger als zunächst gedacht...

Wie hier bereits vorher berichtet, ist meine Seagull eingegangen (naja, nicht so richtig, aber trotzdem tut sie nicht mehr so zuverlässig), als Ersatz dafür hab ich mir eine Yashica MAT 124 besorgt, durchchecken lassen, ein paar Monate damit Spaß gehabt, bis die Lufthansa die Kamera auf dem Weg von Berlin via Frankfurt nach Linz die Kamera im Gepäck zerstört hat. Und "zerstört" heißt: der Lichtschachtsucher ist abgerissen, insbesondere die Schrauben, die ihn am Gehäuse festgehalten haben, der Belichtungsmesser (das Highlight der Kamera) war eingedrückt, der Verschluss hat sich beim Auslösen nicht mehr geöffnet. Immerhin hat die Reiseversicherung, die bei der Kreditkarte dabei war, einen gewissen Teilbetrag anstandslos ausgezahlt.

Nun stand also eine Neubeschaffung im Raum, "tabula rasa", eine neue, robustere Mittelformatkamera. Ich hab mich die Tage davor schon informiert, was sich denn so alles tut auf dem Gebrauchtmarkt, und hatte ein paar verschiedene Modelle im Auge, von Zenza Bronica über Mamiya RB67 bis zu einer aufgemotzten Kiev 88 wie sie z.B. Wiese Fototechnik aus Hamburg vertreibt. Um mir mal ein wenig einen Überblick zu verschaffen, was sich auch bei den Fotohändlern so tut, bin ich gestern nachmittag dann auch noch zu Wüstefeld in Spandau gefahren, und habe dort - neben einigen eher uninteressanten MF-Kameras - ein Prachtstück gefunden, und zwar eine Mamiya C330 mit 80mm- und 135mm-Objektiv, in einem gut erhaltenen Zustand, zu einem so guten Preis, den ich sonst wo nirgendwo gesehen habe. Also hab ich mich spontan entschlossen, diese Kamera zu nehmen.

Die Mamiya C330 ist wie ihre zwei Vorgängerkameras eine TLR, also eine doppeläugige Spiegelreflexkamera, jedoch größer, robuster und schwerer als die meisten anderen Modelle dieser Bauart. Noch dazu hat die Mamiya C-Serie ein paar einzigartige Merkmale, die man sonst bei keiner anderen TLR findet. Zum einen ist es die einzige TLR-Modellserie mit Wechselobjektiven - während selbst Rolleiflex nur 80mm-Objektive drauf hat, kann man hier auf mehrere Objektive im Bereich von 55 bis 250mm zurückgreifen. Zum anderen ist die Kamera mit einem so riesigen Balgen ausgestattet, dass man selbst mit dem 80mm-Standardobjektiv sich mit der Linse bis auf ca. 15 cm an Objekte annähern kann (ein Korrekturfaktor zur eventuellen Anpassung von Blende oder Belichtungszeit wird im Sucher angezeigt). Außerdem findet man ein paar nette Features, so klappt etwa das hintere Teil zum Laden des Films nach unten statt wie sonst nach oben, was das Laden selbst deutlich erleichtert. Außerdem spult man mit einer Kurbel vor, wobei aber trotzdem die Möglichkeit für Mehrfachbelichtungen gegeben wird.

Insgesamt bin ich mit der Neuanschaffung ziemlich zufrieden, die Mamiya C330 scheint auf jeden Fall ein richtiges Arbeitstier zu sein. Morgen wird die Kamera von mir noch genauer ausgetestet werden.

Zum Beispiel, wenn man aus Interesse die defekte Mittelformatkamera (ich hatte darüber berichtet) auseinandernimmt, und draufkommt, dass an dem Verschluss eigentlich garnichts kaputt ist, sondern dass lediglich ein Teil etwas geölt und eine bei einer früheren Reparatur falsch platzierte Trennscheibe wieder richtig platziert werden musste. Das hab ich gemacht, und jetzt funktioniert die Kamera wieder tadellos. argh Und das, nachdem ich so einen großen Aufwand betrieben habe, mir eine neue Kamera zu suchen und diese auch ordentlich warten zu lassen.

Naja, die nächsten Schritte werden jetzt wohl sein, dass ich die sauber entfernte Belederung wieder ebenso sauber anbringe (eine rein optische Sache, technische hat die keine Relevanz), sodass die Kamera wieder in einen verkaufsfähigen Zustand kommt, und möglicherweise werde ich die Kamera, nachdem ich ja mittlerweile besseren Ersatz habe, auch tatsächlich verkaufen.

Gestern war ja Chaosradio zum Thema Wikipedia bzw. der derzeitigen Kontroverse von Exkludismus und Inkludismus. Ich habe mir erlaubt, den meisten Teil der Sendung per Twitter zu verfolgen (ausgenommen der Zeit, wo ich telefoniert hab), und möchte einige der Vorschläge, die in der gestrigen Sendung eingebracht und diskutiert wurden, hier noch einmal zusammenfassen und die Diskussion an sich kommentieren. Teilnehmer der Diskussion waren übrigens Marcus Richter (der Moderator), Sargoth (ein Wikipedia-Admin) und Frank Rieger vom CCC.

Am Anfang dümpelte die Diskussion ja etwas dahin, wobei es doch immerhin zu ein paar interessanten Äußerungen kam: so meinte etwa Sargoth, selbst fundamentale Artikel wie Demokratie wären seiner Ansicht nach in einer absoluten schlechten Verfassung und müssten dringend neugeschrieben werden. Allerdings verstieg er sich später leider in dem Versuch, ad-hoc Relevanzkriterien für Computerspiele zu definieren, was meiner Meinung nach nicht wirklich produktiv war.

Aber schon, was der erste durchgestellte Anrufer zu sagen hatte, fand ich hochinteressant: dieser hatte lt. seinen Angaben einen Artikel über ein Jugendfilmfestival geschrieben (derer es anscheinend nicht wirklich viele gibt), und detailliert aufgezählt, an welchen Wikipedia-Vorgaben und Regeln bezüglich guter Artikel er sich gehalten hatte. Trotzdem wurde dieser Artikel wegen angeblich mangelnder Relevanz gelöscht, was den Autor offenbar ziemlich frustriert hat (man merkte diesen Frust regelrecht in seinen Redebeiträgen), nicht zuletzt aufgrund der vielen investierten Zeit in Artikel und Löschdiskussion. Frustrierte Ansage als Abschluss: "ich würde keinen Artikel mehr anlegen, denn ich will keinen Stress mehr mit Wikipedia haben".

Dann ein paar andere Anrufer und Diskussion, die ich leider nicht mitbekommen habe, weil ich mich natürlich selbst zu Wort melden musste mit meinem Dilemma zum Artikel Musterung (hört selbst rein), und hab damit auch gleich einen kleinen Edit-War ausgelöst...

Frank Rieger sprach sich dann dafür aus, dass auch "irrelevante" Artikel lesbar sein sollten, und meinte damit Artikel die gelöscht wurden, auf die offensichtliche Löschgründe wie Urheberrechtsverletzung, Ehrenbeleidigung, o.ä. nicht zutreffen würden. Das ist ein Vorschlag, den man schon oft gehört hat, und der auch von vielen Seiten als "triviale" Lösung für den Konflikt gesehen wird. Dann sprach er den Wikipedia-Kurier-Artikel an, dem ein seiner Meinung nach elitäres Denken und eine verächtliche Position sowohl der Blogosphäre als auch der Wissenschaft gegenüber anhängt, und sprach einen großen Widerspruch an: einerseits werden Leute mit Fachwissen von der Wikipedia händeringend gesucht, andererseits findet man solche PR-Desaster, und trotz dieser sehr gespaltenen Position wird von Wikipedia-Autoren eine besondere Genauigkeiten verlangt, obwohl Wikipedia nicht einmal selbst einen wissenschaftlichen Anspruch hat und sich auch nicht als zitierfähige Quelle sieht und versteht.

Ein weiterer sehr interessanter Vorschlag, vorgebracht von einem Anrufer, war auch der, Wikipedia in einem größeren Kontext zu sehen, und zwar als Teil einer Gesamt-Wissensdatenbank (das ursprüngliche Wikipedia-Ziel), von der die Wikipedia eine echte Untermenge bildet, d.h. in der Gesamt-Wissensdatenbank sind nur bestimmte Artikel als "enzyklopädisch relevant" markiert. In eine ähnliche Richtung geht auch ein weiterer Vorschlag, Wikipedia allgemeiner zu halten, und spezielleres Wissen in "Spezial-Wikis" oder "Fach-Wikis" auszulagern, derer es ja mittlerweile recht vieler gibt, ich denke da etwa an Indiepedia und Camerapedia als zwei von vielen Beispielen.

Im letzten Viertel der Sendung kam es schließlich zu einer Telefon-Liveschaltung mit Fefe, der ja mit seiner umfangreichen Berichterstattung die Wikipedia-Kontroverse erst so richtig bekannt gemacht hat und ihr auch einen gewissen Schwung gegeben hat. Er vertrat wie schon in seinen Blogartikeln eine sehr offensive Position, und forderte etwa, dass die Relevanzkriterien neu definiert werden müssten. Er argumentierte, dass die allermeisten User, wenn sie nach etwas suchen, einfach einen Suchbegriff in Google eingeben würden. Bei vielen allgemeinen Themen würde als erster Treffer eine Wikipedia-Seite erscheinen, was einen großen Erfolg für die Wikipedia darstellt, denn immerhin steckt hinter diesem Ziel, erster bei Google zu sein, eine Multi-Millionen-Dollar-Industrie. Selbst irgendein (schlechter) Wikipedia-Artikel wäre da besser als garkein Wikipedia-Artikel, denn im Gegensatz zu jeder anderen beliebigen Quelle biete Wikipedia die tatsächliche Möglichkeit für User, die (schlechten) Artikel zu verbessern. Auch Wikipedia-Artikel ohne enzyklopädische Relevanz haben unter diesem Gesichtspunkt einen Mehrwert für die größte Zielgruppe, nämlich Google-User.

Schließlich wurde die Diskussion noch in Richtung Technik gelenkt. Frank Rieger sagte ziemlich offen, dass das MediaWiki, die Wiki-Software, die bei Wikipedia und verwandten Projekten eingesetzt wird, technisch im Jahr 2003 stehengeblieben ist. Hier sollte es mehr technische Hilftsmittel geben, um Usern die Verbesserung von Artikeln möglichst zu vereinfachen. Er erwähnte auch, dass der Wikimedia Deutschland e.V. auf nicht unbeträchtlichen Spendengeldern sitzt, von denen nur ein Bruchteil dafür verwendet wird, einen Toolserver für Wikipedia zu betreiben. Er schlug vor, dieses Geld stattdessen in die Hand zu nehmen und in die Weiterentwicklung von MediaWiki zu investieren. Fefe schlug in diesem Kontext auch vor, dass Wikimedia die Ressourcen und die Möglichkeiten hätte, selbst eine Deletionpedia umzusetzen, die von Wikipedia gelöschte Artikel enthält. Für die deutsche Wikipedia gibt es ja bereits Projekte wie Wiki-Waste, die jedoch deutlich unterdimensioniert sind an Ressourcen.

Schließlich wurde noch auf das Diskussionspanel am 5. November in den Vereinsräumen von Wikimedia Deutschland hingewiesen, und Sargoth schloss mit dem für mich sehr bemerkenswerten Satz, dass die Wikipedia seit ihren Anfängen auch etliche Leute anzogen hat, die Freude daran haben, Artikel zu schreiben bzw. an Wikipedia mitzuarbeiten, sich jedoch mit dem OpenSource-Gedanken nicht identifizieren, und sich auch in konsensorientierte Arbeit noch einfinden müssen.

Mein Fazit ist auf jeden Fall, dass diese zweistündige Diskussionrunde sehr interessant, produktiv und auch konstruktiv war, denn es wurden nicht nur Kritikpunkte an der Wikipedia aufgezählt, sondern auch konkrete Vorschläge vorgebracht, was man an Wikipedia verändern bzw. verbessern könnte. Wie sich diese Diskussion weiterentwickelt, wird sich wohl erst am 5. November zeigen. Und auch das Live-Twittern hat mir Spaß gemacht, auch wenn das stressiger ist, als man sich das denkt.

Meine "Sammlung" an Kameras hat sich in letzter Zeit etwas erweitert, und zwar einerseits um eine wunderschöne Rolleicord I, Baujahr irgendwann 1934 bis 1936 (vielen Dank an Filip und Kathrin für dieses tolle Geburtstagsgeschenk!) und fast zu schön als dass ich sie so nutzen würde wie meine alte Seagull, andererseits um eine frisch gewartete Yashica Mat 124 inklusive integriertem Belichtungsmesser, die wohl künftighin mein "Arbeitstier" in Sachen Mittelformatfotografie werden wird.

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.

Gestern ist meine Seagull 4B1 gestorben. Ziemlich genau 14 Monate hat sie gehalten. Sie war mein Einstieg in die Mittelformatfotografie.

Ich kann mich noch genau erinnern, letztes Jahr im Sommer hab ich auf dem samstäglichen Flohmarkt in Linz diese wahrlich billige TLR-Kamera (sowohl preislich als auch ausführungstechnisch) erstanden. Ich war schon beim Ausprobieren extrem begeistert von der Handhabung dieser Kamera, die sich von anderen Kameras so vollkommen unterscheidet: einerseits eine Spiegelreflexkamera, andererseits eine Mattscheibe, auf die man von oben drauf sieht während man die Kamera ungefähr auf Brust- bis Beckenhöhe hält, das war für mich eine vollkommen neue Sichtweise auf die Fotografie. Schnell hab ich mir 120er-Rollfilme zugelegt, und Fotos über Fotos gemacht. Als Belichtungsmesser diente dabei immer der eingebaute Meter in meiner Zeiss Ikon Contina IIa, was zu immer sehr zuverlässigen Belichtungswerten führte. Durch die vermehrte Beschäftigung mit dieser Kamera fand ich eine vollkommen neue Sichtweise auf die Fotografie an sich.

Und nun ist sie tot, die Seagull 4B1: die Lamellen des Verschlusses federn nicht mehr zuverlässig zurück, wenn der Spannhebel sich nach dem Aufziehen nicht wieder in Ausgangsposition befindet. Gestern habe ich das bei einer eher routinemäßigen Überprüfung der Funktionalität bemerkt. Ob die Kamera vielleicht schon vorher defekt war, wird sich zeigen, nach der Entwicklung von 5 Filmrollen, die ich in meinem Urlaub verbraucht habe. Eine Reparatur wäre lt. einem Verkäufer von Wüstefeld relativ teuer, und stände in keinem Verhältnis zu den damaligen Anschaffungskosten der Kamera.

Nach einem Nachfolger habe ich mich bereits umgesehen, bisher aber nichts befriedigendes gefunden. Für Tipps (oder gar Angebote) bin ich allerdings jederzeit offen. Ich würde auf jeden Fall gerne weiterhin Mittelformat fotografieren, eine TLR muss es aber nicht sein, das "Feeling" sollte aber das gleiche sein (und dazu zählt für mich auch ein Schachtsucher). Eine gebrauchte Rolleiflex ist mir allerdings zu teuer, und eine Hasselblad muss es auch nicht unbedingt sein.

Als Followup auf meinen Artikel "Das freie Wort" dataminen habe ich mir noch die Mühe gemacht, sämtliche Beiträge in DFW runterzuladen, die eigentlichen Texte zu extrahieren, und diese dann mit Hilfe von Wortwolken zu visualisieren (als Tool dafür kam wordle.net zum Einsatz).

Wortwolke November/Dezember 2006:

Wortwolke 2007:

Wortwolke 2008:

Wortwolke 2009:

Wortwolke Mai-Juli 2009:


Eine Wortwolke des gesamten Textkorpus habe ich nicht generiert, da wordle.net mit der Textmenge von 25 MB nicht zurechtkommt. Aus Gründen der einfachen Umsetzung habe ich auf Stemming verzichtet, und mich ebenso beim Filtern von Stoppwörtern auf die in wordle.net integrierte Funktionalität dafür verlassen.

Die Rohdaten gibt's wieder zum Download, und zwar hier.

Eine meiner Meinung nach deutlich umfassendere und auch visuell interessantere Analyse der "Krone"-Leserbriefe von 2008 findet sich übrigens bei wissenbelastet.com, sehr empfehlenswert.

"Das freie Wort" (im Artikel der Kürze wegen "DFW" genannt), die erweiterte Leserbrief- und AgitProp-Kolumne der Kronenzeitung, hat gestern meine Aufmerksamkeit geweckt, nicht zuletzt durch einen tweet von Armin Wolf über einen paranoiden Einwohner von Mistelbach, der beim kleinsten Geräusch in der Nacht seine Wohnung mit Waffe im Anschlag durchsucht.

Nachdem die "Krone" ja berühmt-berüchtigt ist für verleumderische Artikel, Kolumnen, Kommentare sowie (mutmaßlich) fingierte Leserbriefe, habe ich mir die Frage gestellt, "wer ist dieser Herbert Schlemmer aus Mistelbach eigentlich?". Eine schnelle Google-Suche brachte interessanterweise hauptsächlich Hinweise auf DFW in der "Krone". Also die nächste Frage: "wer sind eigentlich diese Leute, die in DFW veröffentlicht werden?". Nun gut, diese Frage kann mit Hilfe der modernen EDV schnell gelöst werden.

Der Internetauftritt der "Krone", krone.at, bietet eine tageweise Übersicht über alle Beiträge in DFW, in der auch sämtliche Leserbriefschreiber inklusive Ort vermerkt sind. Also schnell ein Skript geschrieben, das sämtliche Übersichtsseiten seit dem 1. 11. 2006 runterlädt (das ist offenbar das erste Datum, ab dem DFW derzeit online ist), und ein weiteres, das sämtliche Namen und Orte extrahiert. Mit ein paar kleinen Tools mehr habe ich daraus ein "Ranking" von den am häufigsten publizierten Leserbriefschreibern in DFW generiert, sowie ein Ranking von Orten, aus denen diese Personen stammen.

Zuerst einmal die rohen Zahlen:

• 15872 Beiträge insgesamt im Zeitraum vom 1. 11. 2006 bis zum 28. 7. 2009.


• 854 anonyme Beiträge, d.h. ohne jegliche Angaben zum Autor.


• 384 Beiträge, bei denen "Name und Anschrift der Redaktion bekannt" sind.


• knapp 5200 verschiedene Autoren, d.h. jeder Leserbriefschreiber in DFW hat durchschnittlich etwas mehr als 3 Beiträge veröffentlicht.


• Die Top 20 namentlich genannten Autoren (0,38 % aller Autoren) in DFW haben 20,7 % aller Beiträge geschrieben.


• Die meisten Leserbriefe stammen aus Wien (23 %) (Anteil der Bewohner Wiens an der Gesamtbevölkerungszahl von Österreich: 20,2 %).


• 2190 Beiträge (13 %) wurden per E-Mail ohne Ortsangabe gesendet (zum Vergleich: andere Tageszeitungen verlangen auch bei Einsendung von Leserbriefen per E-Mail eine Adressangabe).


• Auf Wien folgen Graz (420, 2,65 %), Völs (385, 2,42 %), St. Pölten (368, 2,32 %), Strasshof (261, 1,64 %), Linz (250, 1,57 %) und Hirtenberg (174, 1,1 %).

Und hier noch das Ranking der eifrigsten DFW-Autoren (Top 30; die Zahl vor dem Namen ist die Anzahl der Beiträge):

1. 854 (anonym)
2. 498 Franz Weinpolter
3. 384 Name und Adresse der Redaktion bekannt
4. 382 Franz Köfel
5. 333 Helmut Kafka
6. 253 Stephan Pestitschek
7. 164 Hias Rumpler
8. 157 Dr. Erich Schäfer
9. 151 Johannes Abl
10. 139 Heinz Vielgrader
11. 137 Joachim Mayer sen.
12. 128 Willibald Zach
13. 117 Dr. Marian Katschnig
14. 109 Markus Karner
15. 104 Heinz Hoffberger
16. 102 Ing. Harald Schober
17. 98 Roland Reichart
18. 97 Eduard Fitzka
19. 79 Mag. Ewald Hager
20. 77 Ing. Herbert Hurtl
21. 74 Dr. Wolfgang Srb
22. 69 Mag. Günther Schreiber
23. 69 Fred Stöger
24. 64 Günter Kotisch
25. 63 Mag. Martin Behrens
26. 60 Herbert Schlemmer
27. 59 Dr. Karl Hunna
28. 56 Renate Aberl
29. 56 Anton Findeis
30. 55 Kurt Gärtner

Und da finden wir auf Platz 26 auch wieder unseren Herbert Schlemmer wieder.

Das ganze war nur der Anfang: ich ermutige jeden, auf Basis dieser Daten weitere Auswertungen (vielleicht sogar mit Visualisierungen?) anzustellen. Die Rohdaten gibt es hier zum Download. Die Daten dort weichen etwas ab, so ist beispielsweise das "Name und Adresse der Redaktion bekannt" in verschiedenen Formen zu finden und noch unkorrigiert.

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?

gebaut mit Face of the Future und gimp, via Isotopp