Qbi's Weblog

Stellt euch vor, ihr sitzt gerade in einer wichtigen Präsentation. Die Geschäftsführer und Strategen sitzen zusammen und beraten die neue Strategie für das Internet. Zentraler Bestandteil ist die neue Seite Powerportal.firma. Der Vortragende öffnet seinen Browser und gibt die URL ein: http://www.po. Da er den Firefox 3.x verwendet, erscheint nach der Eingabe eine Liste der oft angesurften Seiten. Bei ihm steht auf der Liste www.pornoseiten.foo, www.porno4all.cem usw. und sorgt bei den Teilnehmern für einiges Schmunzeln. Diese oder ähnliche Situationen scheinen sich recht oft zu passieren. Daher gibt es eine immer größere Schicht an Nutzern, die einen Porno-kompatiblen Browser verwenden.

Das Mozilla-Projekt stellte vor kurzem fest, dass viele noch die Version 2 ihres Browsers nutzen und wissen, warum dies so ist. Etwa ein Viertel nannte als Grund die oben beschriebene so genannte Location Bar. PC Pro vermutet die obige Situation als Hauptgrund. Was kann der ungeübte Pornogucker tun, wenn er Firefox 3 haben will und seine Linkliste nicht allen “weitergeben” will? Die praktikabelste Lösung ist aus meiner Sicht ein eigenes Profil. Das bedeutet, es gibt für “privates Surfen” ein Profil und für Firmenbelange ein zweites. Weiterhin bietet die allerletzte Firefoxversion Optionen, um dem Problem zu begegnen. Aber ihr könnt natürlich auch weiter Firefox 2 als Pornobrowser nehmen.

via Pressetext: Pornolinks: Hemmschuh für Browserupgrade

Letzte Woche fand die 860. Sitzung des Bundesrates statt. Dort sollte unter anderem das viel diskutierte Zugangserschwerungsgesetz an der Tagesordnung sein. Ich versuchte im Vorfeld den Ministerpräsidenten mit einem Schreiben mit einigen Argumenten zu überzeugen (siehe auch die Pressemitteilung des AK Zensur dazu). Wie jedoch zu erwarten war, wurde das Gesetz angenommen. Jetzt steht nur noch der Bundespräsident vor der endgültigen Unterschrift und damit vor dem Inkrafttreten des Gesetzes. Der AK Zensur hat einen Appell an Herr Köhler gerichtet.

Beim Betrachten des Ergebnisses fiel mir auf, dass alle Gesetze angenommen wurden, bis auf eines: das Gesetz zur Durchführung gemeinschaftsrechtlicher Vorschriften über das Schulobstprogramm (Schulobstgesetz - SchulObG). Gerade das klingt doch recht sinnvoll. Warum wird sowas nun abgelehnt?

Das Schulobstgesetz geht zurück auf eine Initiative der EU, das EU-Schulobstprogramm. Im Rahmen dessen wurden verschiedene Alternativen untersucht und eine Kommission kam zu dem Schluss, dass die beste Lösung sei, kostenlos Obst an Schüler im Alter von 6 bis 10 Jahren einmal in der Woche auszuteilen. Flankiert mit aufklärenden Maßnahmen gehen die Mitglieder von einem Erfolg aus, d.h. es würden gesunde Essgewohnheiten gefördert werden, die Fettleibigkeit würde zurückgehen und das Risiko chronischer Krankheiten (Diabetes etc.) nimmt ab. Als problematisch werden die Kosten genannt. Die Folgeabschätzung geht EU-weit von Gesamtkosten in Höhe von 156 Millionen Euro (nicht Milliarden!) aus. Daher wurde vorgeschlagen, 90 Millionen aus EU-Mitteln zu zahlen und der Rest aus den Mitteln der jeweiligen Länder. Wenn ich nun den Bericht des Agrarausschusses richtig verstehe, gibt es in Deutschland jetzt Diskussionen, ob Bund oder Länder diese Zusatzmitteln zahlen sollen. Dabei geht es deutschlandweit um eine Summe von 12,5 Millionen Euro oder pro Bundesland um etwa eine Million Euro. Also nach jeglichen Maßstäben Peanuts.

Ich hatte schon vorher mal kalkuliert, welche Gesamtkosten für Thüringen entstehen, wenn alle Kinder täglich kostenlos Obst bekommen. Insgesamt gibt es etwa 300.000 Kinder bis 18 Jahren in Thüringen. Wir zahlen für ein Obstfrühstück im Kindergarten momentan 25 Cent. Wenn man von etwa 200 Tagen in Kindergarten und Schule ausgeht, kämen für Thüringen (aufgerundet) etwa 20 Millionen Euro Kosten zu. Die Zahl ist natürlich nur eine grobe Schätzung. Nichtsdestotrotz würde sie nach meinem Dafürhalten kaum im Portemonnaie des Landes auffallen.

Aber was solls. Lieber zensieren wir den Kindern das Internet weg als ihnen was Gesundes zu Essen zu geben.

Nun sind sie wieder vorbei, die Chemnitzer Linux-Tage. Zwei Tage als Linux-Familienfest.

Wie schon im letzten Jahr hatte ich auch dieses Jahr den Aufruf zum Einreichen von Vorträgen verpasst. Daher kam ich hauptsächlich als Besucher. Einige der Vorträge klangen recht interessant und so wollte ich die Zeit nutzen, um mir diese anzuhören und Ideen zu sammeln. Doch wie so oft kam alles ganz anders. Ich hielt mich sehr häufig außerhalb der Räume auf, traf eine Menge nette Leute und unterhielt mich über verschiedene Themen. Doch natürlich besuchte ich auch Vorträge (wenn auch meist nur zur Hälfte ):

Notensatz mit Lilypond für den Hobbymusiker

Kurz nach meinem Eintreffen in Chemnitz hüpfte ich in diesem Vortrag. David Kastrup stellte das Notensatzsystem Lilypond vor. Das erste Beeindruckende war, dass Emacs auch PDF-Dokumente zeigen kann und zwar inline. David meinte später, dass das mit der aktuellen CVS-Variante (Emacs23) geht. Das PDF zeigte Noten zu Kalinka an und David spielte diese live auf seinem Akkordeon. Der Vortrag wurde immer mal wieder durch solche netten Einlagen unterbrochen. Auf diese Weise war er recht kurzweilig, auch wenn ich über Lilypond nahezu nichts lernte.

Die Telematik im Gesundheitswesen: Was läuft auf Linux in der Arztpraxis?

Ich erwartete von dem Vortrag ein paar Aussagen zu Linux in der Arztpraxis allgemein und eine Diskussion von Vor-/Nachteilen. Die Vortragende erzählte jedoch (zu) viele Details zur elektronischen Gesundheitskarte. So fasste ich recht schnell den Entschluss, die Räume wieder zu verlassen.

I2P - anonymous low latency mix network

Der Vortrag zu I2P interessierte mich natürlich besonders, u.a. deswegen weil ich mit dem Gedanken gespielt hatte, selbst einen zu dem Thema einzureichen. Lars gab einen kurzen Einblick in die Software und die Funktionsweise. Leider war die Zeit zu knapp bemessen, um auf mehr Details einzugehen oder ein praktisches Beispiel zu zeigen. Dennoch waren viele Zuhörer interessiert. Vielleicht konnte so der eine oder andere Nutzer gewonnen werden.

Die Rechtsprechung des Bundesverfassungsgerichts zum Datenschutz: Online-Durchsuchung, Vorratsdatenspeicherung etc.

Johannes Lichdi gab einen Überblick zu den Aufgaben des Bundesverfassungsgerichtes und zeigte anhand der in den letzten Jahren gefällten Entscheidungen, dass das Gericht keineswegs immer Gesetze kippt, sondern vielmehr die Anwendung verfassungsgemäß auslegt und anderweitig minimal eingreift. Sein Fazit war, dass wir das Bundesverfassungsgericht unbedingt zum Schutz der Grundrechte brauchen und auch selbst viel tun müssen. Als kleines Detail am Rande wurde die Broschüre Meine Daten gehören mir! Datenschutz im Alltag (lokale Kopie, PDF, 1,2MB) verteilt. Seite 6 verweist auf mein Buch Anonym im Netz.

Git verstehen und nutzen

Nachmittags wollte ich mir diesen Vortrag noch anhören und hoffte, etwas Neues zu git zu erfahren. Der Vortragende glänzte mit fast 80 Folien, welche im wesentlichen das Tutorial zu git beinhalteten. Hier wäre weniger mehr gewesen. Auf alle Fälle entstand durch den Vortrag bei mir der Plan, selbst einen Workshop oder Vortrag dazu zu machen. Die grundlegenden Ideen zum Ablauf des Ganzen habe ich auch schon im Kopf. Jetzt muss ich nur noch die nächste Linux-Veranstaltung abwarten ...

Quo vadis MySQL?

Wieder ein Vortrag, zu dem ich leider viel zu spät kam. Erkan Yanar gab einen guten Überblick zum MySQL-Universum. Ich würde mich sehr freuen, wenn den Vortrag später als Audio zum Nachhören gäbe.

Analyse und Visualisierung von Daten mit R

Leider war für mich auch dieser Vortrag ein Fehlschlag. Viele Folien und wenig Inhalt. Der Vortragende las viele Funktionen von GNU R vor und am Schluss gab es eine Demo. Diese Übersicht an Funktionen lässt sich auch von der Einführung zu R oder weitergehender Dokumentation gewinnen. Bei der Demo wiederum wurden verschiedene Befehle aufgerufen, ohne dass klar war, was da gemacht wird. Mir wäre lieber gewesen, wenn der Vortragende nach der Einführung kurz erwähnt hätte, dass beispielsweise sämtliche klassischen statistischen Funktionen in GNU R abgedeckt sind (Falls es welche gibt, Ausnahmen nennen). In einer Demo hätte ich mir dann ein kleines Beispiel gewünscht, wo kurz die Datenbasis erwähnt wird und dann später der Vortragende anhand einzelner Befehle die Funktionsweise erklärt. In dem Vortrag habe ich leider nichts von dem Programm mitgenommen. Weder wurde mein Interesse geweckt noch war ich abgestossen.

Verteiltes Suchen – Ein aktueller Überblick

Der letzte Vortrag bei den Chemnitzer Linux-Tagen handelte vom verteilten Suchen. Daniel Gultsch gab einen kurzen Überblick in das Suchen allgemein und stellte später einzelne Projekte (YaCy, Lucene, Wikia und weitere) vor. Dabei kam für mich heraus, dass nur YaCy eine verteilte Suchmaschine ist. Die meisten anderen Projekte decken nur Teilaspekte des Suchens ab. Dennoch scheint YaCy nichts für den normalen Desktop zu sein. Zum einen benötigt das Programm Unmengen an RAM (unter 512MB geht nichts), CPU und anderen Systemressourcen. Zum anderen gibt es nach Aussagen des Vortragenden keine Maßnahmen gegen das Abschalten eines Peers. Der Vortrag selbst gefiel mir gut. Jedoch glänzten die Folien durch Rechtschreibfehler. Würden die Chemnitzer Linux-Tage Preise für Fehler auf Folien verleihen, hätten diese den ersten Platz sicher. Das fand ich sehr schade, da es mich vom Vortrag ablenkte.

Bei vielen anderen Vorträgen hoffe ich, dass es später die Folien oder sogar die Audios gibt.

Am Samstagabend stand nun noch das Keysigning auf dem Programm. Ich hatte vorher die nebenstehenden Hashwerte ausgedruckt. Das sollte helfen, meine Stimme zu schonen und nicht alle Zahlen/Buchstaben durch die Halle brüllen zu müssen. Danach gab ich eine kurze Erklärung zum weiteren Ablauf und Sven bestand auf einem Gruppenfoto.

Schließlich hieß es Aufstellung nehmen. Wir hatten etwa 60 Teilnehmer mit fast 80 Schlüsseln. Ich machte den Anfang und wanderte von Teilnehmer zu Teilnehmer. Der Marsch ging sogar recht zügig. Denn viele hatte ich bereits unterschrieben. Auf dem untenstehenden Foto seht ihr einen Blick in die Menge:

Mir haben die Chemnitzer Linux-Tage in diesem Jahr wieder sehr viel Spass gemacht. Auch wenn die von mir gewählten Vorträge eher Mittelmaß waren. Dafür entschädigt die nette Atmosphäre und die perfekte Organisation. Für mich ist das wirklich wie ein Familientreffen der Linuxfreunde und ich freue mich schon auf nächstes Jahr.

Aufgrund von Änderungen im Protokoll von ICQ funktioniert derzeit Pidgin nicht mehr. Im Yet Another Linux Blog gibt es eine Lösung. Solltest du also Probleme haben, folge einfach deren Anweisungen.

Das nächste Keysigning steht an und wieder einmal stellt sich für alle Teilnehmer die Frage, wie man am besten alle Schlüssel unterschreibt. Ich nutze dafür caff und will euch im folgenden kurz eine Einführung in die Konfiguration des Programmes geben. Hoffentlich hilft das, leichter und schneller zu Ergebnissen zu kommen.

Die Software gehört bei Debian und darauf basierenden Distributionen zum Umfang der Distribution und wird im Paket signing-party ausgeliefert. Andere Distributionen können die Dateien aus dem Subversion auschecken.

caff wird über die Datei .caffrc gesteuert. Im folgenden sind einige Einstellungen genauer erläutert. Dabei reichen meist die ersten vier oder fünf genannten Einstellungen, um caff zum Laufen zu bekommen.

$CONFIG{’owner’} = ‘Max Mustermann’;

$CONFIG{’email’} = ‘mm@example.org’;

$CONFIG{’keyid’} = [ qw{01234567890ABCDE} ];

In den beiden Variablen legt ihr euren Namen, E-Mail-Adresse und die Key-ID eures Schlüssels fest. In der letzten Einstellung kann auch eine Liste von Schlüsseln stehen. Die Key-ID bzw. den Fingerprint eures Schlüssels erhaltet ihr durch Eingabe des Befehls: gpg --fingerprint emailadresse.

$CONFIG{’mail-template’} = <<’EOM’
Text der E-Mail
EOM

Diese Variable trägt den Text der E-Mail, die an die Adressaten verschickt wird. Ihr könnt dort beliebigen Text reinschreiben und auch Variablen lassen sich expandieren. So wird {$owner} durch den oben festgelegten Namen ersetzt, {$key} steht für die Key-ID und {@uids} ist ein Array über alle UIDs. In der Beispieldatei, die mitgeliefert wird, findet ihr auch ein Beispiel zur Anwendung dieser Variablen.

$CONFIG{’mailer-send’} = [ ‘smtp’, Server => ‘mail.example.org’, Auth => [’mm’, ‘GehHeim’] ];

Wenn ihr einen lokalen Mailserver habt, dann ist die obige Einstellung nicht nötig. Sie betrifft vielmehr Anwender, die üblicherweise Programme wie Thunderbird, Evolution etc. nutzen und ohne lokalen Mailserver unterwegs sind. Dann hier muss caff wissen, wie es die E-Mails versenden soll. Meist wird zum Versand ein Smarthost des Providers genutzt. Der Name des Mailservers wird oben eingetragen und innerhalb der eckigen Klammern nach Auth kommen die Zugangsdaten (Benutzername und Passwort).

$CONFIG{’keyserver’} = ‘subkeys.pgp.net’;

Es könnte sein, dass ihr einen anderen Keyserver als den obigen standardmäßig eingestellten Nutzer wollt. Dann solltet ihr subkeys.pgp.net durch den Keyserver eurer Wahl ersetzen. Im Allgemeinen ist dieser aber eine gute Wahl.

Die Software bietet noch eine Vielzahl weiterer Möglichkeiten zur individuellen Steuerung. Diese sind in der Handbuchseite zu caff erklärt. Wie ihr oben schon gesehen habt, hat jede Option den Aufbau $CONFIG{’optionsname’} = ‘einstellung’;. So könnt ihr auch die weiteren in der Manpage genannten Optionen belegen.

Nachdem alle Einstellungen getroffen sind, kannst du dich ans Unterschreiben machen. Das Programm muss mit einer Liste von Key-IDs aufgerufen werden. Doch woher kommen diese? Ich stelle bei den Keysignings, die ich leite, am Ende einen Keyring aller Teilnehmer zur Verfügung. Das macht es einfach, die Key-IDs zu extrahieren:

gpg --no-default-keyring --keyring=KEYRINGDATEI --with-colons --list-keys \
 | awk -F: ‘/^pub/ { print $5 }’

Nun ruft ihr das Programm auf: caff -m yes -u 0x012345 KEYIDS. Die Variable -m steht dafür, die E-Mails ohne Nachfrage zu versenden. Es gibt vier Möglichkeiten, diese zu belegen und wer es will, kann die Einstellungen auch in der .caffrc treffen. Ich persönlich nutze hier lieber die Kommandozeile, um die Option zu übergeben. Mittels -u übergebt ihr die Key-ID eures eigenen Schlüssels. Auch diese Einstellung kann bereits in der .caffrc getroffen werden. Nach einem beherzten Druck auf die Entertaste geht die eigentliche Arbeit los. Ihr werdet Schlüssel für Schlüssel nach eurer Unterschrift gefragt und könnt unterschreiben.

Ich hoffe, diese Anleitung ist für Teilnehmer an einem Keysigning nützlich und hilft, den Aufwand auf ein Minimum zu reduzieren.

Foto von NoirinP.

Jens’ BLOG schreib neulich von zwei Erweiterungen für den Firefox (Nice Firefox plugin (I) und Nice Firefox plugin (II)). Die erste, ShowIP, zeigt euch die IP-Adresse der gerade besuchten Seite. Wenn ihr dann mit der Maus auf die angezeigte IP klickt, werden noch diverse Informationen zu der IP-Adresse abgerufen. Die zweite Erweiterung, ASNumber, geht noch einen Schritt weiter. Hier seht ihr Information zu den autonomen Systemen (AS), also dem ISP der Webseiten. Beide Erweiterungen machen einen recht guten Eindruck und ich teste die mal ein wenig.

Die aktuelle Version lockt mir immer mal wieder ein WTF raus. Gerade war wieder so ein Moment.

Ich spielte ein wenig mit Schriftarten herum und versuchte, eine für mich optimale Schrift wie auch Schriftgröße zu finden. Dabei fiel mir auf, dass die JPG-Bilder auf einmal so pixelig aussehen. Auf der Seite mit den FoeBuD-Bussen sah das Logo unseres Bundeslandes recht unschön aus:

Ich hatte keinerlei Idee, warum dem so ist. Das Zurücksetzen der Schriftgröße bereinigte das Verhalten wieder. Ein Hinweis brachte mich dann auf die richtige Spur. Standardmäßig zoomt der Firefox Schriften und Bilder. Das Verhalten kann man über das Menü Ansicht --> Zoomen --> Nur Text zoomen. Nur warum ist Firefox der Meinung, Bilder zu zoomen, wenn ich einfach eine größere Schriftgröße haben will?

Weitere Gründe sind das Handling von SSL-Seiten. Ihr habt bestimmt schonmal die Meldung example.com verwendet ein ungültiges Sicherheitszertifikat. gelesen. Es braucht vier Klicks bis man eine Ausnahme angelegt hat. Dabei werden die Ausnahmen standardmäßig auch noch permanent gespeichert, was man unter Umständen nicht immer will. Ich fand das Verhalten des alten Firefox in dieser Hinsicht wesentlich benutzerfreundlicher.

Weiter unter dem Punkt ist der gelbe Hintergrund von SSL-Seiten. Bisher war es so, dass SSL-Seiten eine gelbe URL-Zeile erzeugten. Mit der aktuellen Version ist da kein Unterschied (bis auf bereits reichlich kritisierte Ausnahmen) zu sehen. Hier hilft, die Variable browser.identity.ssl_domain_display zu ändern.

Das bringt mich dann gleich zu about:config. Habt ihr das schonmal aufgerufen? Da erwartet euch dann eine fette Warnung, die in etwa sagt, dass ihr jetzt alles kaputt macht. Ich bin ja der Meinung, dass Leute, die das aufrufen und dann auch was ändern, wissen was sie tun. Daher ist die Warnung aus meiner Sicht unnötig.

Ich bin gespannt, wann der Moment kommt, an dem die WTFs aufhören.