Monthly Archives: Juli 2004

Wann funktioniert ein Wiki nicht?

Clay blogt zwei Meinungen über Erfahrungen mit Wikis, die beide - aus ganz unterschiedlichen Gründen - eher negativ sind. Beide haben durchaus ihre Argumente und sind nicht einfach von der Hand zu weisen.

[My Brilliant Failure: Wikis In Classrooms | Kairosnews
, Connected, Distributed Work via Many-to-Many: WhyWikiWorksNot: 2004 Dance Re-mix]

Da ich im Moment ein Projekt begleite, bei dem es um ein Wiki geht, interessiert es mich ganz besonderns, welche negativen Erfahrungen andere gemacht haben.

Ich stelle diesen meine Ideen gegenüber und gehe auf die Schritte ein, die wir tun müssen/sollten, um mehr Erfolg zu haben.

Und weil ich Optimist bin: Die Idee ist gut, jetzt müssen wir es nur noch umsetzten ;)

To really use a wiki, the participants need to be in control of the content- you have to give it over fully.[My Brilliant Failure: Wikis In Classrooms | Kairosnews]

Dieser Punkt ist durchaus einsehbar, vor allem wenn man davon ausgeht, das exakt diese Idee hinter einem Wiki steckt: jeder hat jederzeit vollen Zugang zu allen Inhalten.

80% of my time goes into coordination - communicating with people. […] We made an effort to introduce all involved to the concept of Wiki and use it wherever possible to reduce the time and effort spent in writing/forwarding e-mails and communicating the same idea to a million people in a million ways (ok I’m exaggerating here). However all efforts went in vain.
[…]
Editing other people’s work might only lead to more friction in a diverse work environment than increase the amount of trust. Access control/workflow is the only way to preserve integrity. [Connected, Distributed Work]

Stellt sich die Frage, warum alle Versuche, den Nutzern das Wiki näher zu bringen, gescheitert sind - und, ob man trotz der ursprünglichen Intention von Wikis, dem echten Leben nicht doch den Vorzug geben sollte und Workflow und Zugriffsrechte definieren sollte.

Ein solches Wiki wäre kein echtes Wiki mehr, denn dort gibt es keine unterschiedlichen Rechte oder Aufgaben, jedenfalls keine formalisierten. Informell mag man sich durchaus auf so etwas wie einen Workflow geeinigt haben - vielleicht sogar auf eine Art Schreibschutz für auf bestimmte Weise markierte Inhalte. Doch schon beim Lesezugriff scheitert dieses Modell, denn über die Suche kann man per Zufall über etwas stoßen, das man eigentlich nicht lesen sollte/dürfte/wollte.

Sind die Regeln jedoch formalisiert und werden sie von der Wiki-Engine entsprechend umgesetzt, gibt es keine Grauzonen mehr und man kann sich ‘frei’ weil ‘geschützt’ bewegen. Frei ist hier nicht im Sinne von Freiheit, sondern von Unbeschwertheit gemeint.

Kommen wir nun zu dem o. g. Projekt. Bisher lief nur die Planung und Umsetzung, tatsächlich scharfgeschaltet wurde die Anwendung noch nicht. Kurz zum Hintergrund: es gut um ein Handbuch, das die Arbeit einer Abteilung eines bekannten deutschen Softwarehauses regelt. Dieses Handbuch wird den Mitarbeitern dieser Abteilung weltweit zur Verfügung gestellt und dient als erste und einzige Referenz für deren Arbeit.

Welche Vorteile hat man, wenn man dieses Handbuch als Wiki zugänglich macht? Die Vorgabe war schlicht, das komplette Dokument ins Intranet zu bringen. Von einem Word-Export nach HTML über konventionelle Web-CMS bishin zu Sitemanagementtools zu Frontpage oder Dreamweaver wurde alles angedacht, auch Wikis. Dieser Idee wurde der Zuschlag erteilt weil: klein und schnell; gute eingebaute Suchfunktion; problemlos auf dem Server zu installieren (wenigstens in der Theorie, wir werden sehen ;)) - und vor allem: Inhalte sind ohne Klimmzüge direkt im Browser editierbar, durch die Kommentare besteht die Möglichkeit eines direkten, wenn gewünscht anonymen Feedbacks, alle Feedbacks sind gesammelt an einer Stelle.

Die Umsetzung erfolgt mittels Wikka, einem Wakka-Clon.

Dieses Wiki lässt drei Dinge zu: Erstens die Einrichtung von Zugriffsrechten auf Seitenebene. Man kann für jede Seite sagen, welche Art von Nutzer (Gast, eingeloggt = authentisiert) oder welcher Nutzer (Herr X, Frau Y) welche Rechte hat: Lesen, Schreiben, Kommentieren.
Zweitens: Kommentieren. Da der Schreibzugriff eingeschränkt werden soll, benötigt man eine andere Feedbackmöglichkeit. Statt dies per Mail geschehen zu lassen, sieht die Idee vor, dies in Form von Kommentaren zu tun. Kommentare darf jeder an jede Seite anhängen. Die Kommentare sollen genutzt werden um Fragen zu klären und um Hinweise für neue Versionen des Dokuments zu sammeln.
Schließlich bietet Wikka die Möglichkeit, einen Administrator zu bestimmen. Dieser hat global alle Rechte, kann Zugriffsrechte bestimmen und Dokumente (auch Kommentare) löschen.

Die Situation bisher bzw. mit den anderen vorgeschlagenen Lösungen sähe so aus: Ein statisches Dokument im Intranet. Feedback kommt ungesteuert per Mail zu mehreren Leuten. Änderungen an dem Dokument sind nur über zwei oder mehr Köpfe (technisches Personal, andere Abteilung) hinweg möglich.

Ein Web-CMS hätte zumindest das letzte Problem gelöst, nicht aber den Wunsch, das alles klein und übersichtlich zu halten, vor allem den Aufwand im Hintergrund. Niemand der Beteiligten will eine neue Oberfläche lernen oder sich gar mit Templates oder anderem technischen Kleinkram auseinandersetzen müssen.

Das Wiki hat keine spezielle Oberfläche. Die Seitenansicht ist die einer jeden anderen Webseite. Die Editieransicht sieht aus wie Word im Browser, auch das ist für Büro-Geübte kein Problem. Um Workflows oder Zugriffsrechte muss man sich ebenfalls keine Gedanken machen, da es außer einem Vieraugen-Prinzip (eventuell werden es auch mehr, aber die Anzahl bleibt überschaubar) keinen Workflow gibt, und die Zugriffsrechte automatisch vergeben werden. Ändert sich etwas an denen, ist man mit einer Änderung in der Konfiguration sowie einer kleinen Datenbankänderung dabei.

Von daher also keine Probleme, oder jedenfalls keine unlösbaren.

Hakeliger wird es hinsichtlich der eigentlichen Nutzung und der Nutzer.

Wikis kennen keine formale Struktur, wie man dies von üblichen Web-CMS her gewohnt ist. Die Struktur eines Wikis entsteht beim Schreiben im Wiki. Dies erfordert ein hohes Maß an Disziplin, soll das Ergebnis konsistent und nutzbar sein. Hier werde ich einspringen (müssen) und den Hauptnutzern zumindest die Grundzüge erläutern und mit ihnen gemeinsam Richtlinien schaffen. Im Besten Fall umfassen diese Richtlinien Themen wie: Seitenerstellung, Refactoring, Strukturierung und Navigation. Aber auch die Software hilft beim Strukturieren. OrphanedPages und WantedPages sind in dieser Hinsicht sehr nützliche Tools.

Ohne Nutzer ist das ganze Projekt aber zum Scheitern verurteilt, wie üblich ;) Wird es nicht genutzt, hat man Zeit und Geld verschwendet. Wir müssen den Nutzern also genau erklären, warum wir uns für das Wiki entschieden haben und wie sie aus dem Wiki den größtmöglichen Nutzen für sich ziehen können. Denn subjektiv kanns ihnen wurscht sein, ob das Handbuch als schlichtes Word-Dokument oder eben per Wiki zu ihnen kommt.

People are resistant to change. [Connected, Distributed Work]

Wo sind die Vorteile für die Nutzer? Was ist am Wiki besser als an der alten Lösung?

Direkt eigentlich nur die Suche. Die erzeugt nicht nur eine Trefferliste, sondern liefert die Treffer im Kontext des Dokuments, so daß man leichter erkennen kann, was ein guter Treffer ist und was nicht.

Die wahren Vorteile stecken in der Hintergrundarbeit und müssen von innen nach außen gekehrt werden.

“Weil Ihr direkt auf der Seite (anonym) Feedback geben könnt, haben wir es leichter mit neuen Versionen des Handbuchs weil wir alle Kommentare an einem Platz haben und schneller mit den einzelnen Dokumenten fertig sind. Wir müssen nicht mehr stundenlang im E-Mail-Programm bzw. in uralten E-Mail-Archiven (Outlook) wühlen, statt dessen sind alle Kommentare zu einer Seite direkt auf der Seite sicht- und verarbeitbar. Wenn wir mit Überarbeitungen und Korrekturen schneller sind , könnt Ihr schneller wieder an die Arbeit, verliert weniger Zeit und könnt effektiver arbeiten.”

“Weil Ihr (anonym) Feedback geben könnt, werden Fragen öffentlich beantwortet - im Laufe der Zeit erhält man eine Kommentarsammlung mit Tipps, Hinweisen und Use Cases (auch die Kommentare sind im Volltext suchbar, nebenbei bemerkt.)” [Anm.: Das könnte aussehen wie die User Comments im MySql-Handbuch (etwas nach unten scrollen, sie folgen unterhalb des eigentlichen Dokuments) oder die User Contributed Notes bei PHP.]

“Weil Ihr (und wir) das alles ohne Medienbrüche tun könnt, funktioniert die Kommunikation reibungsloser und weniger Informationsverlust. Keine dauernden doppelten Rückfragen mehr, Unklarheiten können sofort ausgeräumt und Fehler sofort korrigiert werden.”

Fassen wir also zusammen, wie wir unser Ziel erreichen wollen und was wir dafür tun müssen:

Übernahme gewohnter Strukturen aka Workflows und Zugriffsmechanismen sollen die Umgewöhnung für alle Beteilgten so schmerzfrei als möglich machen. Dazu bedienen wir uns der besten Ideen beider Welten, der Wiki-Welt und der Formalismen-Welt des Unternehmensalltags.

Ehrliche Information der Benutzer über die Möglichkeiten des Systems und warum wir glauben, das es besser ist als das alte. Schrittweises Vermitteln unserer Vision und der Vorteile, die mit ihrer Vollendung einhergehen. [Das ist natürlich bei fast jeder Neueinführung, Umstellung, … nötig. Dennoch kann gar nicht genug darauf hingewiesen werden. Viel zu oft wird dieser Punkt vernachlässigt, mit dem Ergebnis, das Neuerungen nicht angenommen werden.]

Eventuell habe ich hier noch das eine oder andere vergessen/übersehen/falsch gedacht. Kommentare willkommen ;)

Nachschlag: XML korrekt ausliefern

Ich bin geneigt, das hier unter Lust und Frust einzusortieren ;)

Nachdem ich die Tage groß und breit von XML, Zeichensätzen und Content-Types erzählt habe, hier ein paar Infos wie man sich solchen Ärger sparen kann.

Testen
Betrifft mich das Problem überhaupt? Und wenn ja, wo muss ich ansetzen? Beide Fragen klärt der iHHC. Nach Eingabe einer URL (ich bitte darum, dieses Tool nicht zu mißbrauchen, sonst verschwindet es ganz schnell wieder) zeigt es die gesamte Antwort des Webservers auf die Anfrage nach der eingegebenen URL. Zum Beispiel hier die URL des WWWorker-Feeds.

Zwei Stellen sind hier wichtig: Erstens die mit Content-type: beginnende Zeile im ersten Teil der Ausgabe, dem HTTP Header. Zweitens die Angabe des XML-Dokuments selbst, zu finden in der ersten Zeile nach dem Header, beginnend mit <?xml (diese Zeile nennt man übrigens XML-Prolog, nur mal so am Rande).

Stimmt die Angabe im XML-Dokument nicht?
Den im Dokument bestimmten Zeichensatz kann man, jedenfalls in den meisten Fällen, leichter ändern als den vom Server mitgeschickten, deswegen fangen wir damit an. Welcher Zeichensatz ist nun eigentlich der Richtige für mein XML-Dokument? Wenn im Dokument nur lateinische Buchstaben ein paar Zahlen vorkommen, kann man ruhig us-ascii nutzen. Kommt aber zum Beispiel das EUR-Zeichen € vor, sollte es iso-8859-15 sein. Zu den Zeichensätzen siehe Teil 1 dieser Trilogie.

Stimmt die Angabe im HTTP Header nicht?
Wie ändere ich den Zeichensatz für meine XML-Dokumente? Per Webserverkonfiguration. Bei Apache httpd geht das per

AddCharset iso-8859-15 .xml

Diese Zeile kann auch in einer .htaccess-Datei definiert werden (siehe Context: in der AddCharset-Doku.

Wenn wir nun schon dabei sind, checken wir doch gleich noch den vom Server angegebenen Content-type. Für RDF sollte dieser application/rdf+xml lauten, für RSS application/rss+xml und für Atom, richtig geraten, application/atom+xml. Das bekommen wir mittels AddType auch problemlos hin.

Fies wirds wenn wir, wie im Fall des WWWorkers, zwei verschiedene Feeds anbieten: einen RSS 2.0- und einen Atom-Feed. Beide haben die Dateiendung .xml. Der RSS-Feed bekommt aber einen anderen Content-Type als sein Atom-Bruder. Dank der Files-Direktive gelingt auch dies. Hier der Einfachheit halber ein Auszug aus dem .htaccess-File des WWWorker:

AddCharset iso-8859-15 .xml
AddType application/rss+xml .xml

<Files atom.xml>
	ForceType application/atom+xml
</Files>

Was geschieht hier: Zunächst bekommen alle Dateien mit der Endung .xml den Zeichensatz ISO-8859-15 verpasst. Außerdem wird all diesen Dateien der Content-Type application/rss+xml zugewiesen. Die Datei atom.xml erfährt eine Spezialbehandlung, ihr wird per ForceType application/rss+xml aufgezwungen.

An dieser Stelle sollte das Dokument mit korrektem Zeichensatz und korrekter Content-Type-Angabe ausgeliefert werden.

Und was sagt der Feedvalidator?
Strenggenommen kann uns dessen Meinung egal sein. Er ist nämlich kein SGML-Parser, und damit eigentlich nicht geeignet, hundertprozentige Aussagen über ein XML-Dokument zu machen. Aber seis drum, er ist das Beste, was wir haben.

URL eingeben, ENTER drücken und warten. Im besten Fall gratuliert er schlicht. Im schlechtesten ist der Feed sowieso nicht wohlgeformt, und wir haben uns all die Mühe für einen kaputten Feed gemacht. Los, reparieren! Im zweitbesten Fall meckert der Feedvalidator nur noch über ein oder zwei Zeichen, die er nicht korrekt auflösen kann. In diesem Fall passt entweder der Zeichensatz nicht 100%ig (zum Beispiel wurde ISO-8859-1 angegeben, das Dokument enthält aber das EUR-Zeichen €, das es nur im -15er gibt), oder die Anwendung, die den Feed erzeugt hat, macht Fehler.

Im Falle des WWWorker ist dem so. Aus unerfindlichen Gründen generiert Movable Type das EUR-Zeichen als XML-Entität, die leider mit dem Zeichensatz ISO-8859-15 nichts zu tun hat. Wer hier eine Idee hat, was falsch läuft oder wo ich krumm denke, her damit.

Sollte ein Eingriff in die Konfiguration des Webservers nicht möglich sein, hier noch ein kleines PHP-Skript, das XML-Dokumente nach außen hin kapselt. Mit Perl, Python, whatever ist das mit Sicherheit auch möglich.

<?php
header('Content-type: application/rss+xml; charset: iso-8859-15');
readfile('index.xml');
?>

Dieses Skript kapselt immer nur ein Dokument, man braucht also für jedes Dokument, das man kaspeln will, ein Skript.

Frühstück, ich komme! Bis demnächst in diesem Theater.

Wurm prüft E-Mailadressen über Suchmaschinen

WORM_MYDOOM.M verbreitet sich mittels SMTP und Emails. Auf befallenen Systemen sucht der Malicious Code zunächst nach einem Internetanschluss und verbindet sich daraufhin über einen Mail-Exchanger. Darüber hinaus werden Email-Adressen potenzieller Angriffziele aus der Windows Address Book Datei gesammelt und mittels Suchmaschinen wie Google oder Yahoo überprüft. Der Wurm fälscht zudem die Absenderadressen der infizierten Nachrichten. [MYDOOM.M tarnt sich als Meldung von Email-Systemen]

Weitere Quellen: Google News ‘mydoom+suchmaschinen’

XML hat im Web versagt - Teil 2

Was bisher geschah. Es gibt zig Zeichensätze. Welchen man benutzt, ist erstmal egal, nur muss man dies konsequent tun. XML-Dokumente müssen sagen, in welchem Zeichensatz sie zu lesen sind. HTTP legt auch einen Zeichensatz für Dokumente fest. Verschickt man also XML-Dokumente über HTTP hat man zwei Angaben über den Zeichensatz. Die XML-Spec sagt nun, das man bei doppelten Angaben denen des übergeordneten System trauen soll, in diesem Fall also denen von HTTP. Problematisch dabei: das XML-Dokument enthält deutsche Schriftzeichen, der Webserver steht aber in den USA und sendet alle Dateien mit der Zeichensatzangabe ascii aus - dieser Zeichensatz kennt keine Umlaute, das XML-Dokument ist demnach nicht wohlgeformt, peng.

Um die Verwirring perfekt zu machen, spielt neben der Angabe des Zeichensatzes auch die des Content-types in HTTP eine Rolle. In dem RFC 3023 wird nämlich festgelegt, welcher Zeichensatz bei welchem Content-type anzunehmen ist, wird kein Zeichensatz angegeben. So legt der RFC fest, das Dokumente, die als text/xml verschickt werden, den Zeichensatz us-ascii verpasst bekommen.

Das Problem liegt also im Zusammenspiel von XML und HTTP. HTTP kann Dokumente sinnvollerweise nur an Äußerlichkeiten erkennen, zum Beispiel der Dateiendung, und alle Dateien mit dem gleichen Merkmal gleich behandeln. Die Alternative wäre, bei jeder Anfrage die Angaben über Content-type und Zeichensatz direkt aus dem Dokument herauszulesen - mit dem Ergebnis, das XML-Anwendungen im Web verdammt langsam werden würden.
XML hingegen legt diese Angaben auf Dokument-Ebene fest. Äußerlichkeiten wie Dateiendungen sind XML egal, solange der Inhalt valides XML ist, wird jeder Parser es als solches erkennen und verarbeiten können.

Die Lösung des Problems muss an zwei Stellen erfolgen. Zum einen müssen Webserver korrekt konfiguriert werden, so daß sie verschiedene Typen von XML-Dokumenten mit dem korrekten Content-type ausliefern. Zum anderen müssen XML-Applikationen und Webserver aufeinander abgestimmt werden, damit beide den gleichen Zeichensatz für das selbe Dokument verwenden. Technisch ist das relativ einfach zu lösen, beispielsweise über Weiterleitungen oder dynamische Auslieferung durch Skriptsprachen, die den Content-type/charset-HTTP-Header selbst für jedes ausgelieferte Dokument setzen.

XML hat im Web versagt

Die Kernaussage lautet: 44% einer Stichprobe von n=5096 Feeds von Syndic8 sind nicht wohlgeformt, also ist XML am Ende.

Das zugrundeliegende Problem hat allerdings strenggenommen nichts mit XML zu tun, sondern mit Zeichensätzen und der Art und Weise, wie Daten per HTTP übertragen werden.

XML.com: XML on the Web Has Failed [via cyDome - Fast die Hälfte der RSS-Feeds ist ungültig]

Zeichensätze gibts wie Sand am Meer. Da wären zunächst mal die alten Bekannten ASCII und ANSI, die Veteranen unter den Zeichensätzen. ASCII, aus dem Jahre des Herren 1968, umfasst einen Zeichensatz von 2^7, also 128 Zeichen, kodiert in einem Byte pro Zeichen. Darin enthalten sind 32 nicht sichtbare Steuerzeichen, das lateinische Alphabet in Groß- und Kleinschreibung, die Ziffern von 0-9, nordamerikanische Satzzeichen und ein paar Sonderzeichen, die man zum Programmieren braucht. Keine Äs und ßs, keine spanischen Satzzeichen, keine französischen Anführungsstriche.

Danach kam ANSI, bzw. ISO 8859. Immerhin 256 Zeichen, und damit auch die wichtigsten Sonderzeichen. Allerdings immer noch nur für Sprachen mit lateinischem Alphabet. Hier leistete sich Microsoft eine Extrawurst. Man baute den auch Latin-1 genannten ISO 8859-1 um nannte ihn Windows-ANSI.

Die ISO 8859-Familie besteht aus ca. 16 Zeichensätzen. Wieso ca.? Weil der keltische Zeichensatz zwar geplant (die Nummer wurde sozusagen reserviert) aber nie verabschiedet wurde. Die ISO 8859-Zeichensätze für arabisch, kyrillisch und andere nicht-lateinische Alphabete sind teilweise unzureichend umgesetzt. Zum einen Aufgrund der Beschränkung auf 256 bzw. 224 (32 Steuerzeichen) Zeichen, zum anderen weil es bessere Alternativen gibt.

Auftritt Unicode. Unicode stellt einen Versuch dar, alle Zeichen aller lebenden Sprachen abzubilden. Dazu sieht der Standard pro Alphabet eine Zeichentabelle vor. Die Zeichen selbst sind durchnummeriert von 0 bis 65535. Unicode kennt also 65536 verschiedene Zeichen für eine ganze Reihe von Schriftsätzen, darunter das Runenalphabet, Braille oder graphische Elemente.
Unicode bläht (vier Bytes pro Zeichen, 2^16 = 65536) jeden ASCII-Text um das Vierfache auf. Heutzutage kein so großes Problem mehr, das durch relativ billige Massenspeicher gelöst werden kann.
Nein, Unicode bläht nicht jeden ASCII-Text um das Vierfache auf. Es gibt Varianten, die jedes Zeichen mit nur zwei Byte darstellen, die Textgröße also nur verdoppeln. Und es gibt eine 1-Byte-Variante, da ändert sich nichts an der Größe und sogar eine 7-bitige Variante, die nur die 2^7 ASCII-Zeichen enthält.

Daneben gibt es noch Windows-1252 , MacRoman und bestimmt noch ein paar andere, die ich nicht kenne.

Zurück zur Aussage, XML hätte im Web versagt. XML sieht vor, das für jedes Dokument explizit der Zeichensatz angegeben wird, mit dem es erstellt wurde und zu Lesen ist. Soweit kein Problem, als XML-Entwickler weiß man dies und implementiert es entsprechend.

Wird eine XML-Datei (das könnte im Sinne dieses Textes ein HTML-, ein XHTML- oder ein Feed-Dokument in RSS, RDF oder Atom sein), markiert als mit ISO 8859-1 erstellt, nun über das Web-Protokoll HTTP an einen Browser geschickt, so gibt HTTP der Datei einen HTTP-Header mit. Und in diesem findet man neben neben allen möglichen technischen Daten auch eine Angabe für den verwendeten Zeichensatz. Das Problem dabei: woher weiß HTTP, welche Zeichensatzangabe es in den Header packen soll?
In der Regel geschieht dies durch Konfiguration des Webservers, der die Datei verschickt und dafür sorgt, einen ordnungsgemäßen Header mitzuliefern. Der Server steht in den USA und sendet alle Dokumente mit der Zeichensatzangabe us-ascii aus. Dumm nur, wenn im XML-Dokument aber iso-8859-15 steht, weil zum Beispiel das EURO-Zeichen € vorkommt, das der Zeichensatz US-ASCII nicht kennt.

Welche Angabe also sollte das verarbeitende Programm, hier der Browser, benutzen? Der XML-Standard sagt hierzu deutlich, das die Angabe des übergeordneten Systems zu verwenden ist. XML wird über HTTP übertragen, also wird die Angabe im Dokument ignoriert und der HTTP-Header zur Entscheidung der Zeichensatzfrage herangezogen.

Der sagt us-ascii, dieser Zeichensatz kennt kein EURO-Symbol, das Dokument ist nicht wohlgeformt, peng.

Der Autor geht an dieser Stelle erstmal frühstücken. Bis später.

Schlamperei bei Spiegel TV

To: spon_spiegeltv@spiegel.de
CC: spon_leserbriefe@spiegel.de
Subject: Leserbrief zum Artikel Die Flucht des Phantoms: Der Fall Pfahls und die Geheimnisse der Kohl-Regierung (ID:+308398)

Sehr verehrte Damen und Herren,

betreffend des Beitrags ‘Das Schwert der Scharia’ möchte ich Sie bitten,
in Zukunft Begebenheiten so darzustellen, wie sie tatsächlich sind.

Besonders das Gespräch mit dem Mitarbeites eines Domain-Registrars in
Düsseldorf zeigt durch Fragen wie ‘Aber Sie sehen doch, was auf der
Webseite steht, das kann man doch wissen, Sie aber kassieren nur und
schauen weg’ (sinngemäß und zusammengefasst) deutlich, das die Redaktion
entweder aus Nicht-Verständnis der Technik oder - und das wäre
schlechter, gegen den Pressekodex verstoßender Journalismus -
absichtlich zur Erzeugung eines gesteuerten Meinungsbildes Sündenböcke
schaffen will.

Ein qualifizierter technischer Berater hätte Ihnen bereits im Vorfeld
erklären können, das diese Frage mit dem Domain-Registrar den Falschen trifft.

Ich hoffe abschließend, das dieser Faupax lediglich auf Schlampigkeit
bei den Recherchen und nicht auf willentlicher Manipulation zur
Vergrößerung des medialen Effekts beruht.

Mit freundlichen Grüßen, Sascha Carlin

23-net

Das 23-net ist ein junges deutsches IRC-Netzwerk mit einer sehr elegant gestalteten Website. Über die Website können Mitglieder einen Webmail-Client nutzen, chatten und sich im Forum austauschen.

Das mit phpBB realisierte Forum wirkt sehr aufgeräumt und übersichtlich. Und Haustiere gibts auch ;)