Month: October 2009

Während die meisten Kubuntu Nutzer gerade ihr Upgrade auf Karmic machen, bin ich nach vier Jahren Kubuntu auf Debian Squeeze/Sid (und teilweise Experimental) gewechselt. Die Gründe hab ich eigentlich schon mal ausführlich hier aufgeführt. Um sie noch mal kurz zusammenzufassen:

• Übersetzungen: ich weiß, dass es diesmal besser ist, dennoch war mit den 4.3 Paketen für Jaunty endgültig die Schmerzgrenze überschritten. Auch musste ich sehen, dass sämtliche Kubuntu Anpassungen, wie das Notify-OSD, nicht übersetzt sind. Ein Problempunkt auf den ich den zuständigen Entwickler vor mehr als einem Monat aufmerksam gemacht hatte, dass das passieren wird.
• Ayatana: mich stören ganz stark die Anpassungen von Canonical an KDE. Es ist Canonicals gutes Recht ein neues Benachrichtigungssystem zu entwickeln und dies ohne Community Mitarbeit zu machen. Dies dann aber teilweise an die Nutzer auszuliefern (wie den MessageIndicator) finde ich aber nicht gut und das ist nichts was ich noch nutzen will (vor allem mit obigen Punkt). Hinzu kommt, dass der MessageIndicator als Plasmoid meiner Meinung nach völlig falsch implementiert ist (auch darauf hab ich den Entwickler hingewiesen). Dass man dies besser hätte mit KStatusNotifierItem umsetzen können, wurde diese Woche erneut auf den Mailinglisten diskutiert. Scheine hier also nicht ganz alleine mit meiner Meinung zu sein 😉
• Plasma Netbook Shell: Kubuntu liefert in Karmic eine “technical Preview” der mit KDE 4.4 kommenden Plasma Netbook Shell aus. Dies ist aktuell pre-alpha und benötigt an vielen Stellen KDE 4.4 und ist daher nicht das was aktuell in trunk ist. Auch hier ist es wieder Canonicals gutes Recht das zu tun, aber ich denke nach dem 4.0 Debakel, an dem Distributionen nicht ganz unschuldig waren, hätte man so etwas besser sein lassen sollen. Wie man darauf 18 Monate Support geben soll, ist mir unklar. Aussagen wie “This is a supported release just like Kubuntu or Ubuntu” macht mir in dem Zusammenhang Angst für den allgmeinen Fall.

Interessant ist, dass ich zwei mal bisher die Distribution gewechselt habe und beide Male nicht ein Vorteil der neuen Distribution der ausschlaggebende Faktor war, sondern eher die Unzufriedenheit mit der zuvor verwendeten. Das letzte Mal war es SUSE und ich war nicht wirklich mit YAST und RPM zufrieden.

Die Debian Installation hatte mehr Probleme verursacht als ich erwartet hatte. Mein Testsystem funktionierte einwandfrei. Jedoch hatte ich nicht mehr an die Probleme mit EFI auf dem MacBook gedacht und konnte dann das System nicht starten. Erst nachdem ich mehrmals erfolglos war, kam ich auf die Idee mal im Internet zu schauen 😉 Danach funktionierte dann GRUB, nur um beim Update auf testing (hab mit einer Lenny CD installiert) erneut vor einem nicht bootenden System zu stehen wegen dem Update auf GRUB2. Da ich mittlerweile angenervt war und keine Lust hatte mich mit GRUB2 auseinanderzusetzen, wurde wieder grub-legacy installiert und System läuft wieder.

Nun konnte endlich auch mal eine grafische Oberfläche installiert werden und hab prompt vergessen apt-pinning einzurichten und hab nun mehr sid als squeeze. Da ich mittlerweile sehr angenervt war, bleibt es nun dabei 😉

In KDE selbst, gibt es wie bei Debian nicht anders zu erwarten keine negativen Erfahrungen. Nein ich bin sogar positiv – sehr positiv – überrascht. Die KWin Effekte fliegen geradezu. Ich hab es selten so flüssig erlebt. Ich weiß nicht ob das bei Karmic nun auch der Fall wäre aber es ist sehr angenehm. Selbst unter den harten Belastungen wie ich kompiliere gerade mal KDE und benutze den Würfel zum Wechseln der Arbeitsfläche treten keine Ruckler auf. Das ganze System fühlt sich viel reaktiver an und ich frage mich zum ersten Mal ob an dem ganzen “KDE ist in Kubuntu langsam” doch was dran ist. Nun mal abwarten wie das aussieht, wenn der Rechner ein paar Tage Uptime hat mit Kdevelop & Co. ständig geöffnet.

Die nächste unangenehme Überraschung trat am Folgetag (gestern) auf. Wegen Bauarbeiten in meinem Zimmer (neue Fenster) musste ich mit meinem Rechner umziehen nur um feststellen zu müssen, dass ich noch keine WLAN Treiber installiert hatte. Wie sich später rausstellte, ist dieser proprietär (also nicht überraschend). Ich wollte eigentlich an meinem “geheimen” Programmierprojekt arbeiten, aber zum Kompilieren von kdepimlibs fehlte mir noch ein Paket, daher können sich jetzt die KDE Nutzer freuen, denn ich hab mal wieder einen halben Tag KWin Bugs behoben – dank git und meinem guten Gedächtnis geht das auch ohne Internet. Und da ich dabei war, hab ich heute gleich weiter gearbeitet und es gibt nun einen schnellen Fenstervergrößerungsmodus (wie in Compiz) und ein MacOS like Alt+Tab (nur Anwendungen).

Mittlerweile ist das System ganz gut aufgesetz. Alles wichtige ist installiert. Leider musste ich häufiger zum selbst Handanlegen wechseln als mir Recht war. Da hat der Pragmatismus von Ubuntu zu proprietären Treibern doch Vorteile. (Ich muss unbedingt alle Treiber sammeln, damit ich nicht ohne X dastehe, beim nächsten Kernelupdate). Das einzige was mich aktuell stört, ist, dass ich den Bildschirm in der Helligkeit nicht verstellen kann. Unter Ubuntu ging das. Muss ich mich mal genauer auf die Suche des Problems machen. Der Treiber ist eigentlich im Kernel vorhanden.

=-=-=-=-=
Powered by Blogilo

Die aktuelle von Fefe angestossene Diskussion zur Lösch(un)praktik der Wikipedia ist für mich mal ein Grund die Wikipedia mit dem Wiki von Ubuntuusers zu vergleichen. Ich denke bei der Wikipedia – zumindest der Deutschen – läuft seit einiger Zeit einiges falsch. Es ist ja nicht die erste Löschdiskussion und gerade die “Relevanzkriterien” sind bei mir schon öfter mal sauer aufgestossen. Mittlerweile schaue ich bei jedem Artikel auch auf die Englische Wikipedia. Zum Vergleich: wenn ich ein Linux “Problem” habe, ist meine erste Anlaufstelle das Ubuntuusers Wiki und erst wenn ich dort nicht fündig werde, gehe ich zur Suchmaschine.

Nun lässt sich überhaupt die Wikipedia mit dem uu Wiki vergleichen? Auf den ersten Blick nein. Die Wikipedia ist eine Enzyklopädie, das uu Wiki ist eine kleine Sammlung von technischen Artikeln. Jedoch gibt es große Übereinstimmungen:

• Beides sind Wikis
• Beide leben vom Mitmachen der Leute
• Beide sind freie Projekte
• Beide haben eine selbstgeschriebene Softwarelösung
• Beide sind in ihrem Umfeld die Nummer 1 in Deutschland
• Bei beiden gibt es eine Gruppe Ausgewählter, die das letzte Wort haben

Ich denke bei Ubuntuusers läuft es besser. Aber warum? Ich sehe da zwei Gründe:

1. MediaWiki eignet sich nicht zur Diskussion
2. Ubuntuusers hat das Baustellen Konzept

Die Diskussion bei der Wikipedia erfolgt im Rahmen der Möglichkeiten von MediaWiki und das ist ein Wiki. Es gibt daher zu jedem Artikel einen Anhang als Diskussion, welcher wiederum eine Wiki Seite ist. Ein Wiki ist aber kein Diskussionsmedium. Schaut man sich die aktuell so schönen öffentlichen Diskussionen an, sieht man, dass man mit einer Wiki Seite keine sinnvolle Diskussion erreichen kann.

Ubuntuusers verwendet zur Diskussion verknüpfte Forenthreads. Ein Forum ist ein Diskussionsmedium und bietet damit eine gute Grundlage um konstruktiv und sinnvoll zu diskutieren. In einem Forum sieht man sofort wer wo wann gepostet hat, es steht nicht alles untereinander, sondern ist sinnvoll strukturiert. Man sieht bei ubuntuusers sofort ob der Schreiber gerade eine Wikimoderator, Supporter, ehemaliger oder sonstwas ist. Dazu gibt es noch den Postcounter und das Anmeldedatum, die angezeigt werden. Klar nicht wirklich aussagekräftig, aber es hilft doch die Sockenpuppen aufzudecken. Gäbe es bei uns eine Diskussion wie die zum Löschantrag von Fefes Blog würde sofort auffallen, dass es Sockenpuppen sind und wir könnten mit den Forenmoderatoren zusammen eine gute Reaktion ausarbeiten.

Den zweiten Vorteil von Ubuntuusers ist das Baustellenkonzept. D.h. neue Artikel können nicht direkt im Wiki angelegt werden, sondern nur in der Baustelle. Das ist bei einem technischen Forum essentiell wichtig, da nur so sichergestellt werden kann, dass keine fehlerhaften oder gefährliche Anleitungen ins Wiki eingebaut werden. Für den Schreiber hat es auch den Vorteil, dass er sich erst mal austoben kann und erst wenn er fertig ist, sich den Moderatoren stellen muss 😉 Ich denke dieses Konzept wäre auch für die Wikipedia nützlich. Der aktuelle Fall zeigt es ja wieder: würde zuerst der Artikel komplett erarbeitet werden inklusive der Relevanzbeweise, dann hätte man nicht schon nach wenigen Minuten eine Löschdiskussion. Größere Überarbeitungen werden übrigens auch nur in der Baustelle vorgenommen und solange wird der eigentliche Artikel gesperrt. Das hat den Vorteil für den Schreiber, dass er sich austoben kann und auch den kompletten Artikel erst mal kaputt machen kann und für den Wikimod, der die Änderungen korrigiert (vielen Dank an der Stelle noch mal an das Webteam für den RSS Fead – dafür gibt’s ein Bier beim nächsten Teamtreffen), dass er diese Änderungen erst mal ignorieren kann. Wäre für die Wikipedia auch interessant.

Nun klingt das alles ja ganz toll, aber woher soll man nun wissen, dass es wirklich besser ist? Dazu möchte ich einfach mal anmerken, dass wir in den etwa 1,5 Jahren, die ich im Wikiteam nun bin, keine einzige Seite sperren mussten wegen einem Editwars. Wir haben auch meines Wissens nach noch nie einen User sperren müssen. Gut wir zwingen die Anmeldung am Portal um Änderungen vornehmen zu können – muss aber auch sein, sonst könnte der User nicht mitdiskutieren.

Auch bietet uns die Software noch mehr nette Möglichkeiten. So haben wir – ja man glaubt es kaum – einen internen Diskussionsbereich und einen geschützten Wikibereich. Dass unsere interne Diskussion nach Außen getragen wird und plötzlich bei Fefe verlinkt ist, kann uns nicht passieren 😉 (Nein wir diskutieren nichts schlimmes intern, meistens geht es nur um Sachen wie Verbesserungen an unseren Vorlagen. Das geht im kleinen Kreis halt einfacher. Wikiartikel selbst diskutieren wir öffentlich).

Nun und jetzt noch etwas zum Löschen. Ja wir löschen auch. Aber nur ganz selten. Wir löschen eigentlich nie Artikel aus dem Wiki. Ist ein Artikel veraltet so wird er ins Archiv verschoben. D.h. er ist immer noch vorhanden. Gründe für so etwas ist nicht mehr vorhandene Software wie z.B. Beryl. Gelöscht werden maximal Artikel, die unsere “Relevanzkriterien” nicht erfüllen und das sind dann “nur” Artikel in der Baustelle. Das kommt sehr selten vor und wird immer nur nach dem Vielaugen Prinzip angewandt (und wir bieten dem Autor immer auch an den Artikel auf seine Benutzerseite zu stellen). Ein Beispiel wäre ein Artikel zu einem Windowsspiel welches ohne Anpassung mit Wine läuft. Dafür braucht man einfach keinen Artikel 😉

Auch wenn das uu Wiki viel kleiner ist, könnte die große Wikipedia meiner Meinung nach von uns Lernen. Ich hoffe auch dass die Löschdiskussion nicht abebbt, sondern zum Umdenken in der Wikipedia führt. Ich denke die Wikipedia schadet sich selbst. Wenn in der englischsprachigen Wikipedia mehr steht zu aktuellen deutschen politischen Ereignissen, dann ist das für mich ein deutliches Indiz dass was falsch läuft. Ich denke für die Wikipedia sollte gelten: “Verbessern statt Löschen”

=-=-=-=-=
Powered by Blogilo

Da ja aktuell im Planet von ubuntuusers einige Posts zum Betriebssystemtest der Chip sich sammeln, möchte ich auch noch meinen Senf dazu abgeben.

Was mich am meisten stört, ist dass von Kubuntu eine Alpha Version verwendet wurde. Ist im Artikel nicht erwähnt kann man aber leicht am Screenshot erkennen. So ist klar ein KDE 4.3 erkennbar. Dies gibt es erst in Karmic oder über Backports für Jaunty. Da man aber hervorhob, dass es eine neue KDE Version in dem Kubuntu gibt, gehe ich davon aus, dass es Karmic ist. Die Screenshots erlauben übrigens eine ziemlich genaue Datierung. Im Panel fehlt das “Message Indicator” Plasmoid welches in Alpha 4 eingefügt wurde – also vor dem 13. August. Eine Alpha Version in einem so frühen Stadium zu testen, nun ja, kann sich jeder selbst sein Bild von machen. [Update]Zumindest die beigelegte Live-CD ist ein Jaunty mit 4.3 über Backport Quellen und weiteren Fremdquellen. Was nun zum Einsatz kam für den Test, kann ich nicht sagen. Eine Backport Quelle wäre jedoch noch fahrlässiger als eine Alpha.[/Update]

Was man an den Screenshots auch schön erkennen kann, ist, dass Compositing nicht aktiviert ist. In dem Abschnitt “Fazit” steht “die fehlenden Treiber bei Kubuntu sind klare Nachteile”. Da sehe ich doch einen Zusammenhang: fehlende Treiber und kein Compositing. Bei Jaunty wäre mir keine moderne Grafikkarte bekannt, die keinen Treiber hat. Wenn es eine Ati oder NVIDIA Karte ist, würde man im Systemabschnitt der Kontrollleise einen Hinweis sehen, dass Treiber verfügbar sind. Wie man im Screenshot erkennen kann, ist dieses Symbol nicht zu sehen und es gibt auch keine ausgeblendeten Symbole. Dies bestätigt meinen Verdacht der verwendeten Alpha Version.

Der Screenshot verrät viel mehr als man denkt. So sieht man, dass noch die KDE 3 Version von K3B verwendet wird, im kommenden Karmic ist aber die KDE 4 Variante. Selbst das Icon ist noch die KDE 3 Variante, in Jaunty mit Backports hat man die Oxygen Variante. [Update]Es reicht nicht nur nach dem Symbol in KRunner zu schauen – in Jaunty wird auch das KDE 3 Icon angezeigt.[/Update] Der Screenshot wurde am 09.09. aufgenommen. Interssant ist das Dolphin Fenster, dort sieht man einen Geändert Zeitstempel welcher 3 Minuten vor der aktuellen Zeit liegt. Die Kubuntu CD ist eingehängt, eine vorhandene Festplatte jedoch nicht. Wenn in der Titelleiste nicht “chipuser” stehen würde, würde ich behaupten das ist ein Screenshot aus einer Live-CD. Jedoch macht mir “Wir haben für Sie eine angepasste CHIP-Edition von Kubuntu auf die Heft-DVD gepackt” in dem Zusammenhang Angst. Eine Live-CD zu remastern und den kubuntu User in chipuser umzubenennen ist nicht wirklich schwer, daher gehe ich davon aus, dass es eine Live-CD ist.

Die Bildunterschrift ist natürlich der absolute Hammer: “Eine Übersichtsfunktion für offene Fenster gibt es nicht”. Das ist eine dreiste Lüge. Hätten sie eine stabile Version verwendet, hätten sie auch die Übersichtsfunktion gesehen. Ganz toll, dass man gerade zwei Funktionen der Konkurrenz gezeigt hat, die wir beide unterstützen.

Wäre ich Autor der entsprechenden Effekte Present Windows oder Taskbar Thumbnails, dann wäre der Presserat informiert und die Chip dürfte eine Gegendarstellung veröffentlichen. Leider bin ich aber von diesen Funktionen nicht der Autor. Dennoch wurde eine Gegendarstellung im Forum erarbeitet und eine Unterschriftenaktion gestartet. Wer sich an dieser – aus meiner Sicht sinnreichen und korrekten – Aktion beteiligen möchte, kann sich im Forum zuschalten oder sich wohl auch gerne bei AlphaX2 melden.

=-=-=-=-=
Powered by Blogilo

Dies ist ein Folgeartikel zu meinem gestrigen Artikel, dass das Verschleiern von E-Mail Adressen nicht funktioniert und nutzlos ist. Viele Kommentare zu dem Artikel sagen, dass sie meinen dass die Verschleierung doch hilft, weil sie der Meinung sind, dass Bots nicht an den verschleierten Adressen interessiert sind.

Um noch mal zusammenzufassen: wir nutzen Verschleierung um zu verhindern, dass Spam Bots E-Mail-Adressen ernten. Wir verschleiern auf eine Art, so dass

• Menschen die E-Mail-Adresse lesen können

• Computer die E-Mail-Adresse nicht lesen können

Das klingt nach einem CAPTCHA. Falls ihr die “was erlaubt ist und was nicht” zu CAPTCHAs nicht kennt, empfehle ich die Lektüre der Informationen auf captcha.net. Eine der wichtigsten Fakten ist, dass man kein CAPTCHA verwenden sollte, dass nicht mehr funktioniert, sobald alle es benutzen. Also in dem Augenblick wenn die Bots das CAPTCHA unterstützen.

Kommen wir zurück zu den verschleierten E-Mail-Adressen.Ich denke wir können uns darauf einigen, dass Verschleierung vom Konzept her nicht funktioniert. Ich denke wir können es mit Kryptographie vergleichen: obwohl es noch keinen wirklichen Anwendungsfall zum Angriff auf MD5 gibt, würde wohl niemand MD5 noch verwenden um wichtige Dokumente digital zu signieren.

So bald die Harvester anfangen nach verschleierten E-Mail-Adressen zu suchen, werden sie sie finden. Wenn man heute eine E-Mail-Adresse im Web verschleiert und in fünf Jahren die Harvester anfangen Adressen zu entschleiern, werden sie die Adresse finden. Pech gehabt.

Also anstatt ein nicht funktionierendes CAPTCHA wie die Verschleierung zu verwenden, sollte man ein sicheres CAPTCHA wie den Mailhide Dienst von reCAPTCHA verwenden. Es existieren Plugins für viele Programmiersprachen und es könnte verwendet werden um z.B. automatisch alle E-Mail-Adressen in Mailman Archiven durch einen Link zum CAPTCHA zu ersetzen. Dies sieht wie folgt aus: jsm…@example.com

Das Lösen von reCAPTCHAs ist meistens bedeutend leichter als von normalen CAPTCHAs, weil man ein komplettes Wort lösen muss und es ist wahrscheinlich auch einfacher zu lösen als eine komische Verschleierungsregel. Und es hilft Bücher und Zeitungen zu digitalisieren und am Ende bekommt man einen anklickbaren E-Mail-Link.

Ich weiß, dass ihr jetzt sagt “reCAPTCHA gehört zu Google und Google ist böse. Ich möchte Google nicht meine E-Mail-Adresse geben”. Falls ihr das denkt, denkt nach. Denkt ihr wirklich, dass der größte Web Harvester der Welt die einfache Verschleierung nicht brechen kann? Habt ihr noch nie eine E-Mail an eine gmail/googlemail Adresse gesendet? Ihr nutzt kein Jabber mit Google Talk Nutzern? Ihr habt keinen Google Account? Denkt ihr wirklich Google hat nicht schon längst eure E-Mail-Adresse? Und wenn ihr wirklich reCAPTCHA nicht vertraut, dann kann man immer noch scr.im verwenden um eine CAPTCHA gesicherte Kurzurl zu erhalten. Aber ich empfehle die Verwendung eines gut getesteten CAPTCHA Systems.

Zusammenfassend: Ich stimme zu, dass man die E-Mail-Adressen auf Webseiten schützen soll. Aber bitte macht euch den Gefallen und macht es richtig. Verschleierung ist gebrochen und es ist nur eine Frage der Zeit, bis die Harvester anfangen verschleierte Mails abzugrasen. Es gibt Dienste welche ein sicheres CAPTCHA zum Schutz der E-Mail-Adressen anbieten. Bitte diese verwenden. Und nein dies ist keine Werbekampagne für reCAPTCHA – es ist einfach nur der beste CAPTCHA Dienst den ich kenne. Falls jemand einen besseren kennt, der sicherer ist und nicht Google gehört: bitte Kommentar hinterlassen – ich bin interessiert.

Viele Leute verschleiern ihre E-Mail-Adresse auf Webseiten in der Hoffnung, dass Bots diese nicht aus der Webseite extrahieren können. Das könnte wie folgt aussehen:

email [AT] example [dot] tld

Diese Vorgehensweise wird zum Beispiel von Mailmans Archiv Pipermail und der MARC E-Mail Schnittstelle, welche von KDE Mailinglisten verwendet wird, angewendet. Manche Leute bitten sogar darum “E-Mail-Adressen nicht unverschleiert im E-Mail Text zu zitieren”.

Ist das Verschleiern von E-Mail-Adressen überhaupt sinnvoll? Gewinnt man dadurch mehr Sicherheit?

Die Antwort ist Nein. Die Verschleierung ist eine CAPTCHA Variante (Completely Automated Public Turing test to tell Computers and Humans Apart). Ein CAPTCHA erfordert, dass ein Computer das Künstliche Intelligenz Problem nicht lösen kann, wenn er Zugriff auf alle Informationen hat, welche benötigt werden um den Test zu erstellen. Gestern hab ich versucht zu beweisen, dass diese Art von CAPTCHAs geknackt ist und hab dazu eine kleine Anwendung geschrieben, welche die E-Mail-Adressen von einem öffentlichen Pipermail Archiv extrahiert. Die Anwendung besteht aus weniger als 300 Zeilen Code und kann automatisch alle E-Mails für einen gegebenen Monat und Jahr herunterladen und die Sender Adresse extrahieren durch das Rausziehen aller a Elemente der online abrufbaren E-Mail. Auf diese Elemente wird ein regulärer Ausdruck angewendet um die E-Mail Adresse zu erhalten. Ich wollte eigentlich nur etwa eine halbe Stunde daran arbeiten, am Ende hab ich dafür Qt 4.6 kompiliert, weil ich das neue QWebElement benötigte 😉 Falls jemand Interesse am Quellcode hat, kann ich ein Repository auf gitorious anlegen.

Das folgende Bild zeigt das Ergebnis eines “Angriffs” auf das plasma-devel Archiv. Aus Datenschutzgründen hab ich den Nutzerteil der E-Mail-Adressen unlesbar gemacht.

Picasaweb

Ich bin der Meinung, dass keine verlässliche Möglichkeit existiert E-Mail-Adressen nur durch Text zu verschleiern. Wenn es einen Algorithmus zum Verschleiern gibt, dann gibt es auch einen regulären Ausdruck um die Verschleierung aufzuheben. Die einzige Möglichkeit eine E-Mail-Adresse zu schützen, ist sie nirgends anzugeben wo ein Bot sie aufsammeln könnte. Dazu könnte man sie durch ein “echtes” CAPTCHA ersetzen, welches die E-Mail-Adresse nach dem Lösen preisgibt. Für Webseiten existiert zum Beispiel die Mailhide API von reCAPTCHA. Für Mailinglisten ist das ganze komplett nutzlos, da die Adresse sowieso unverschleiert in den E-Mail Headern steht. Anstatt Webseiten zu parsen könnten Bots auch einfach die Mailingliste abonnieren.

Also bitte hört auf die E-Mail Adressen zu verschleiern. Es ist nutzlos und man kann nicht mehr auf E-Mail Links klicken. Stattdessen muss der Leser ein nutzloses CAPTCHA lösen.