Author Archives: mrtux

Windows Vista: Diktatur des Systems

Heute früh habe ich noch gedacht, dass ich zur Zeit gar nichts habe, worüber ich bloggen könnte – gerade ist mir wieder etwas über den Weg gelaufen:

Für meinen HiWi-Job an der Uni habe ich einen Labor-Arbeitsplatz bekommen. Das ist ein angenehmer Raum, der arbeitsam eingerichtet ist und mit guter Rechentechnik ausgestattet ist. Der Nachteil: Auf den Maschinen läuft Windows Vista. (Darüber will ich jetzt nicht allzu sehr meckern, ich könnte auf das alternativ installierte Fedora Linux ausweichen – aber dann würde ich mich darüber beschwerden …)

Um die Sicherheit des Systems zu erhöhen, sind automatische Updates installiert. Die werden nach einem mir nicht bekannten (weil eigentlich uninteressanten) Prinzip angestoßen und laufen im Hintergrund ab.

Gerade wurde solch ein Update durchgeführt. Und damit die Änderungen auch wirksam werden, muss (wie bei Windows schon immer üblich) das System neugestartet werden. Ich hätte erwartet, dass mir genau das mitgeteilt wird – mit der Option, den Neustart jetzt auszuführen oder auf einen späteren Zeitpunkt zu verschieben.

Aber bei Vista scheint zu gelten: Rechne nicht damit, lass Dich überraschen!

Jedenfalls erschien in der rechten unteren Bildschirmecke ein Fensterchen, das mich freundlich darauf hinwies, dass mir noch ganze 5 Minuten bis zu einem unabwendbaren Systemneustart bleiben.

Da frage ich mich doch: Was erlaubt Microsoft sich eigentlich? Ich möchte mit dem System arbeiten – und zwar, wann es mir passt, nicht, wenn das System mal Lust dazu hat! Wenigstens die Möglichkeit, den Neustart abzuwenden, hätte ich erwartet.

So hat mich die Aktion “nur” 10 Minuten Arbeitszeit gekostet. Was passiert, wenn ich auf dem Rechner eine aufwändigere Berechnung laufen lasse? Vielleicht noch über Nacht? Muss ich damit rechnen, morgens ohne Ergebnisse dazustehen, weil das Betriebssystem zwischendurch mal neustarten wollte? Offenbar ja.

Bevor ich mich daran mache, Dinge zu tun, die ich nicht innerhalb von 5 Minuten unterbrechen kann, muss ich mir also noch ein vernünftiges Betriebssystem zulegen oder aber die automatischen Updates deaktivieren.

Um mal, abschließend, einen Gruppennamen aus einem mittlerweile nicht mehr ganz so beliebten Studentenportals zu zitieren: “War doof, merkste selber, ne?”

XOrg vs. Eclipse

Als ich am Montag nach einem System-Update (Debian sid) mein Eclipse starten wollte, erschien statt der erwarteten IDE ein Fensterchen mit der Meldung, es hätte einen Fehler in der JVM gegeben. Eclipse konnte nicht gestartet werden, dementsprechend konnte ich meine Arbeit auch nicht fortsetzen.

Da man den Fehler ja zuerst bei sich selbst sucht, habe ich erst einmal das Update des Java Development Kit rückgängig gemacht und die Version 1.5 installiert. Der Fehler blieb leider.

Ein Blick auf die Console hat folgendes ergeben:
The program 'Eclipse' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 1272 error_code 11 request_code 148 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Eine Suche nach den entsprechenden Schlagworten hat mich schnell in die überall präsenten Ubuntu-Foren geführt, wo sich herausstellte, dass der Schuldige das Paket xserver-xorg-core ist, das mit Einführung eines Sicherheitsupdates das Ausführen von SWT-Applikationen mit eben dieser Meldung quittiert.

Die spontane Lösung dafür ist, das Update rückgängig zu machen und eine ältere Version zu installieren. Die habe ich auf den Paketservern leider nicht mehr gefunden, da dort nur die jeweils aktuellen Versionen vorliegen. Fündig geworden bin ich dann im Paket-Cache auf meinem eigenen Rechner, wo ich zum Glück noch eine ältere Version dieses Paketes hatte; manchmal ist es doch praktisch, nicht immer sofort alle Caches zu leeren. :)

Sollte jemand mit dem gleichen Problem hier vorbeikommen, kann er das mit folgenden Befehlen beheben:

wget http://www.tuxathome.de/deb/xserver-xorg-core_2%253a1.4.1%7Egit20080105-2_i386.deb
dpkg -i xserver-xorg-core_2%3a1.4.1~git20080105-2_i386.deb

Das installiert die Version, die vor dem Update ausgeliefert wurde. Es empfiehlt sich, die Version vom 18.01. als Forbidden zu markieren, damit sie beim nächsten Upgrade nicht gleich wieder installiert wird.

Achtung: Ich übernehme keinerlei gewährt für die Korrektheit und Verfügbarkeit des Paketes auf meinem Server oder den ordnungsgemäßen Ablauf des Downgrades!

Ich werde noch einen Bugrepot anfertigen (den habe ich jedenfalls nicht gefunden) und bin gespannt, wie lange es dauert, bis das Problem behoben ist. Mein Eclipse läuft jedenfalls erstmal wieder.

SMTP-DSN: Warum einfach …

… wenn es auch kompliziert geht.

Hintergrund ist folgender: Ich habe für eine Plattform ein Mailinglisten-System implementiert. Das war notwendig, weil es dort sehr spezielle Regeln zur Generierung der Empfänger gibt, die jedes Mal dynamisch angewendet werden müssen. Bestandteil dieses System ist natürlich auch die Erzeugung von Bounces, um Fehler und Ausnahmezustände mitzuteilen.

Dabei ist mir etwas aufgefallen: Es gibt drei nette RFCs, die sich mit dem Format dieser Delivery Status Notifications (DSN oder kurz Bounce) beschäftigen:

Diese Konventionen regeln, wie eine Bounce-Message aufgebaut ist, wie die Informationen abgelegt werden, welche Fehlercodes es gibt und so fort.

Und nun kommt unser kompliziertes Leben: Kein Mail User Agent, den ich kenne, wertet die Bounces anhand dieser RFCs aus! Statt dessen bekommt der – mittlerweile oft laienhafte – E-Mail-Nutzer eine kryptische Fehlermeldung zu sehen, die häufig so interpretiert wird, dass die Adresse nicht existiert. Das ist ein beliebter Grund für Bounces, aber oft auch falsch.

Liebe MUA-Programmierer: Warum gibt es keine Ansicht fuer Bounces, in der die Informationen aufgeschlüsselt sind und auch den Nutzern, die E-Mails nicht per telnet lesen können, verständlich gemacht werden? Das würde einen weißen (nein, eigentlich schwarzen) Fleck auf der Landkarte der E-Mail-Kommunikation beseitigen.

Die Auferstehung des Zaurus: Anforderungen

Nach dem ersten Beitrag zu diesem Thema geht es nun um die Anforderungen, die ich an ein mobiles PIM-Gerät stelle. Natürlich beziehe ich mich an dieser Stelle wieder speziell auf meinen Zaurus, jedoch denke ich, dass auch für andere Geräte interessante Anregungen dabei sind.

Ich gehe dabei von drei Aspekten aus:

  • Benutzerfreundlichkeit (im Neusprech auch als Usability bekannt)
  • Sicherheit
  • Aktualität der Daten

Benutzerfreundlichkeit bedeutet dabei, dass sich die Software unterwegs gut bedienen lassen muss, also auf eine vorhersehbare Interaktion und gegebenenfalls auch eine stiftlose Bedienung zugeschnitten ist.

Wer gerade in der Stadt unterwegs ist, möchte nicht ständig den Blick auf dem Display haben, weil die Bedienschritte selbst bei Routineaufgaben ständig unerwartete Wendungen nehmen (einige Mobiltelefone sind mit dieser Interface-Krankheit geradezu verseucht) und auch nicht jedes Mal den Stift herausholen, um nachzuschauen, was am Tag noch ansteht oder einen Punkt auf der TODO-Liste abzuhaken. Das besonders kleine Display und eine mögliche Bedienung des Touch-Screens mit dem Finger müssen bedacht werden.

Genauso wichtig ist aber, dass die Anwendungen selbst auf ihren speziellen Verwendungszweck zugeschnitten sind. Eine Kalenderanwendung wird verwendet, um nachzuschauen, welcher Termin als nächstes ansteht oder um einen Termin zu vereinbaren. Dabei sehe ich immer wieder Anwendungen, die den Prozess der Terminvereinbarung eher behindern als unterstützen: Nicht nur, dass es keine Unterstützung zum Finden freier Termine gibt, häufig wird z.B. auch verlangt, dass erst einmal Betreff und Ort eingegeben werden, bevor es möglich ist, eine Zeit festzulegen. Hier wird missachtet, dass bei der Terminvereinbarung die Zeit im Mittelpunkt steht – die übrigen Metadaten lassen sich selbständig und im Nachhinein ergänzen. Gleiches passierte mir schon regelmäßig beim Anlegen von Kontakteinträgen: Es gibt nicht wenige Mobiltelefone, die zuerst die Eingabe des Namens verlangen, bevor eine Telefonnummer eingegeben werden kann. Wenn ich jedoch das Telefon heraushole, um eine Nummer zu speichern, ist es eben die Nummer, die mir zuerst und vor allen Dingen von meinem Gegenüber diktiert wird. Und diese Nummer möchte ich zuerst speichern können. Das sind Kleinigkeiten, die sich jeoch ganz massiv auf die Zweckmäßigkeit des Gerätes auswirken.

Wichtig für mich ist vor allem eine schnelle Übersicht der Dinge, an die ich zu dem Zeitpunkt denken sollte, zu dem ich auf meinen PDA schaue.

Sicherheit wird dann wichtig, wenn unbefugte Personen Zugriff auf meinen PDA erhalten. Sei es in einem unbeaufsichtigten Moment oder bei Verlust des Gerätes. Schlimmer als die Notwendigkeit, Hardwareersatz und die verlorenen Daten zu beschaffen ist nämlich der Umstand, dass diese Daten in fremden und sehr wahrscheinlich den falschen Händen sind.

Ebenfalls nicht zu verachten ist die Möglichkeit, dass man abends, nachts oder zu einer beliebigen anderen Zeit auf der Straße angehalten und zur Herausgabe seines Gerätes gezwungen wird. Mir ist das zum Glück noch nie passiert, aber bei der Entscheidung Hardware oder Gesundheit gewinnt eindeutig letztere. Wenn es dann möglich ist, die Daten zu entfernen oder wenigstens unzugänglich zu machen, verliert diese Situation an Schrecken.

Wie erreicht man das? Die Lösung setzt sich für mobile Datenträger und auch auf einigen Desktops mittlerweile schon durch: Sämtliche persönlichen oder sensiblen Daten sollten ausschließlich verschlüsselt abgelegt werden. Beim Einschalten des Gerätes muss eine PIN eingegeben werden (unter Berücksichtigung der Benutzerfreundlichkeit), die den Crypto-Container freischaltet. Wer versucht, unbefugt an die Daten zu gelangen, wird nichts vorfinden, was von Nutzen ist. Da der Zaurus über einen SD-Port verfügt, bietet sich an, diesen Container auf einer SD-Karte abzulegen. So sind auch Datensicherungen sehr schnell gemacht, weil nur ein Image der SD-Karte gezogen werden muss. Einen halbwegs intelligenten Räuber kann man vielleicht sogar noch dazu überreden, auf die SD-Karte zu verzichten. So bleiben aktuelle Daten erhalten.

Grundsatz sollte auf jeden Fall sein, keine sensiblen Daten offen und unverschlüsselt zu lassen. Mit einer vernünftigen Verschlüsselung hat der PDA einen gewaltigen Vorteil gegenüber jedem low-tech-Papierplaner.

Aktualität der Daten muss durch entsprechende Synchronisationsverfahren gewährleistet werden. Nur wenn die Daten überall auf dem neusten Stand sind, kann man sich auch auf sie verlassen und auf deren Basis Entscheidungen treffen.

Der Zaurus, wie ich ihn beschrieben habe, hat zwei Schnittstellen: Den USB-Port und eine CF-WLAN-Karte.

Der USB-Port ist in ein Cradle integriert, das auch zum Aufladen des Gerätes verwendet werden kann. Beim Einstellen des Gerätes sollte also ein Abgleich sämtlicher Daten erfolgen. Wenn möglich, vollautomatisch. Auftretende Konflikte sollten an einem beliebigen Gerät gelöst oder später bearbeitet werden können. (Warum schließlich soll ich mich mit dem Mini-Display des PDA abmühen, wenn direkt daneben ein ausgewachsener Desktop-PC steht?)

Die Synchronisation mittels WLAN sollte ähnlich laufen, kann jedoch auch von unterwegs erfolgen. Zu beachten ist hier, dass es auch zu einem Abbruch der Verbindung kommen kann, also eine entsprechende Transaktionsverwaltung nötig ist.

Ziel der synchronen Datenhaltung ist, jede Information auch nur einmal eingeben zu müssen und sie trotzdem an jedem meiner PIM-Geräte zur Verfügung zu haben.

Fazit: Wer sich sein eigenes Handy oder einen handelsüblichen PDA betrachtet, wird schnell feststellen, dass keines der Geräte alle diese Aspekte erfüllt. Spätestens bei der Verschlüsselung wird auf aktive Sicherheit gesetzt und nicht beachtet, dass insbesondere Speichererweiterungen auch am System vorbei ausgelesen werden können. Benutzerinterfaces sind häufig nur verkleinerte Varianten eines Desktops und für kleine Touch-Screens oder die Bedienung mit nur wenigen Tasten ungeeignet. Auch die Synchronisation klappt in den wenigsten Umgebungen reibungslos. Es gibt viel Nachholbedarf, bis ein PDA wirklich effektiver ist, als ein Papierplaner und man mit solch einem Gerät Zeit spart.

Schicker Minirechner mit Debian

Den Titel der Heise-Meldung musste ich doch nach der Begutachtung des Gerätes glatt mal übernehmen.

Die Rede ist von einem Debian-basierten Desktop-Rechner im Office-Format. Das heißt, er ist nicht überdimensional groß, sondern hat mit (18×11,2×4,8)cm das Format eines etwas dickeren Manuscripts, komplett passiv gekühlt, damit also kaum hörbar und hat dazu nur 12 Watt Leistungsaufnahme, was einen Dauerbetrieb über den gesamten Arbeitstag unbedenklich macht.

Vorinstalliert ist besagtes Debian-System mit dem KDE-Desktop, Firefox und OpenOffice. Damit sollten die meisten Anwendungsfälle abgedeckt sein.

Leider gibt es keinen Testdownload des angebotenen Systems – Debian lässt sich schließlich auf die unterschiedlichsten Arten konfigurieren, wie die verschiedenen Derivate zeigen und auch über die Update-Fähigkeit werden keine Aussagen gemacht. Zweites Manko ist der Preis von 450 Euro – dafür bekommt man durchaus schon einen recht leistungsfähigen PC oder kann einen weniger leistungsfähigen PC 2 Jahre lang mit Strom versorgen. Die Office-Eigenschaften müssen hier gezielt gewünscht und mit viel Geld erkauft werden. Denkbar wäre aber eine Subventionierung solcher Geräte im Rahmen eines Umweltschutzprojektes.

Für mich käme das Gerät wohl nicht in Frage, da es als Entwicklungsrechner nur begrenzt einsetzbar ist. Sowohl Prozessor als auch Hauptspeicher entsprechen nicht mehr den heute üblichen Voraussetzungen. Trotzdem würde ich darauf gern mal ein bis zwei Tage testarbeiten – ich kann mir gut vorstellen, dass sich alle anderen Dinge damit sehr gut erledigen lassen.

KDE PIM: Kalenderreparatur

Ich habe mich vorgestern abend gefreut, dass doch tatsächlich noch eine Version 3.5.8 der KDE mit einer großen Menge von Bugfixes über den Debian Paketstream geliefert wurde. Leider kam dann gestern auch die Ernüchterung: Seit dem Update funktionierte mein Kalender nicht mehr.

Um auch von anderen Rechnern aus auf meine Kalenderdaten zugreifen zu können, benutze ich einen IMAP-Account zur Ablage der Kalenderdaten. Die einzelnen Einträge werden dabei im ical-Format in jeweils eine E-Mail gelegt. Ich finde das sehr praktisch, weil es sich gut speichern lässt, für IMAP eine Menge Bibliotheken vorhanden sind und man so auch mit anderer Software leicht zugreifen kann.Die Fehlermeldung war:

libkcal: ERROR: Can't read uid map file

Damit das im Kontact verwendet werden kann, muss man im KMail einen Groupware-Ordner angeben, unterhalb dem dann die PIM-Daten (Kalender, Notizen, Kontakte und Journal) abgelegt werden. Seit der Version 3.5.8 (bzw nach den Newsgroups wohl schon ein wenig früher) hat sich diese Konfiguration wohl geändert, jedenfalls ist nun ein Eintrag notwendig, um zu kennzeichnen, welcher IMAP-Account für die Daten zuständig ist. Das musste ich von Hand nachpflegen.

Eine Anleitung, was dabei zu tun ist, gibt es in folgendem Foreneintrag: https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/139433/comments/7

Damit funktioniert mein Kalender nun wieder und ich kann mich auch wieder ordentlich organisieren. Nebenbei ist mir aber mal wieder aufgefallen, wie sehr man sich doch von der Funktion bestimmter Tools abhängig macht. Es wird Zeit, dass ich mir eine zweite Alternative für den Zugriff auf diese Kalenderdaten suche.

Virtualisierung: Protected Mode 2.0?

Mit der Einführung des Protected Mode auf den i386-Prozessoren und der Ermöglichung des hardwaregestützten Multitasking-Betriebs wurden Rechnernutzung und Betriebssysteme auf dem PC-Sektor revolutioniert.

Lange Zeit gab es keine Neuentwicklungen – wenn man von speziellen Befehlssätzen wie SSE, MMX und multiskalaren Architekturen absieht (die den Prozessor zwar schneller und leistungsfähiger machen, aber keine konzeptuellen Neuerungen bringen).

Mittlerweile wird Virtualisierung immer mehr zum Thema und auf Prozessorebene mit der Paravirtualisierung zunehmend unterstützt.

Einige Fragen, die mir gerade in den Sinn kamen:

  • Ist die Virtualisierung der Nachfolger des Protected Mode?
  • Wird sie ebenso viel Auswirkungen auf unsere Systeme haben?
  • Und wie werden spätere Nutzungsszenarien aussehen?
  • Findet man neue Konzepte für die Struktur eines Desktop-Betriebssystems?
  • Oder bleiben wir dabei, mehrere Systeme auf einer Maschine zu integrieren und belassen Virtualisierung in einem “Nischendasein” für Serverarchitekturen?

PIM-Synchronisation: Es könnte so einfach sein…

Für ein Projekt, über das ich später umfangreicher berichten werde, habe ich die Standards für das Speichern und Austauschen von Kalender- und Adressbuchinformationen recherchiert.

Dabei habe ich ohne viel Mühe Standards für folgende Aufgabenstellungen gefunden:

  • Ablegen beliebiger Objekte in zentralen Speichern, z.B. IMAP und LDAP
  • Darstellen von Visitenkarten (vCard)
  • Darstellen von Kalendereinträgen, TODOs, Journals und Austausch von Verfügbarkeitsinformationen (iCalendar)
  • Austausch von Kalenderinformationen (iTIP, iMIP)

Außerdem ein RFC, das sich mit dem Zusammenspiel dieser Protokolle beschäftigt.

Meine Fragen:

  • Warum ist es trotzdem nicht möglich, die PIM-Daten auf Handy, PDA und PC miteinander abzugleichen, einfach mal einen Termin zu verschicken oder die Aushandlung eines Termins meiner Kalenderapplikation zu überlassen?
  • Warum gibt es proprietäre Formate zum Austausch dieser Informationen?
  • Ist die Welt nicht schon kompliziert genug?

Wer Antworten hat, ist herzlich eingeladen, einen Kommentar abzugeben.

Wir haben's doch!

Ich weiß ja, dass ich in Bezug auf Resourcen-Sparsamkeit von Software mittlerweile als hoffnungsloser Idealist dastehe und ein weiterer RAM-Riegel billiger ist als eine Optimierung. Aber was ich gerade bei Heise gelesen habe, wirkt doch nach:

Da gibt es auf heise security einen Bericht über einen Virus, der MP3-Dateien löscht. Darüber mag man spekulieren und Verschwörungstheorien entwickeln, jedoch reicht es nicht für einen Blog-Eintrag kurz vor dem Schlafengehen.

Hängengeblieben bin ich an dieser Textstelle im zweiten Absatz:

Nach der Infektion des Systems verankert sich der in Delphi programmierte Deletemp3 in den Windows-Autostarts

HALLO?! Sind wir wirklich schon so weit, dass wir Viren in Delphi schreiben und eine Verknüpfung in den Autostarts reicht, um ihn auszuführen? Wo sind die Hacker, die sich Nächte damit um die Ohren schlagen, ein Virus in den Bootsektor zu bekommen? Mit Assembler, nicht Delphi!? Wo bleibt denn da der Stil?

Offenbar ist es aber auch nicht gelungen, das Virus korrekt zu programmieren:

Aufgrund von fest einprogrammierten Programmpfaden soll der Wurm jedoch unter Windows 2000 nicht korrekt laufen

Also, liebe Script-Kiddies: Wenn ihr schon mit Viren rumspielen müsst, obwohl ihr gerade mal Delphi beherrscht, dann macht es doch bitte richtig. Noch haben die Hacker einen Ruf zu verlieren. Und die Hersteller der Antiviren-Software einen Job, wenn man sich vor Viren in Zukunft nicht mehr fürchten muss, weil sie eh nur noch als fehlerhafte Beta-Version auf den Markt kommen.

;)

Ist Google wirklich böse?

Ein SPIEGEL-Artikel vom 18. Juni, “Ein Tag ohne Google”, hat mich gemeinsam mit der Lektüre des Artikels “Politische Psychologie: Thomas Kliche weiter befragt” von Hanno’s Blog motiviert, doch einmal folgende Frage zu erörtern: “Ist Google wirklich böse?”

Google, obwohl zu Zeiten seines Aufstiegs wegen der guten und schnellen Suchmaschine bejubelt, verliert immer mehr an Ruf und Vertrauen. Schuld daran ist das, was Google überhaupt erst zu einer Suchmaschine macht: Das Sammeln, Aufbereiten und Wiederfinden jeglicher Daten, die sich im Internet anhäufen.

Aber noch einmal zum Kerngeschäft: Sammeln, Aufbereiten und Wiederfinden jeglicher Daten, die sich im Internet anhäufen.

Google wird so gern beschuldigt, unsere geheimsten und persönlichsten Daten preiszugeben und es jedem dahergelaufenen Kriminellen zu ermöglichen, unser Leben auszuspähen. Dabei zeigt uns Google eigentlich nur eins: Welche Daten wir selbst in die öffentlichen Weiten des Internet bugsiert haben und was theoretisch jeder Andere über uns wissen könnte.

Dass man nur mit Kenntnis eines Namens herausfinden kann, wer derjenige ist, wo er wohnt und wie er ist, wird durch Google mit Sicherheit begünstigt, jedoch keineswegs grundlegend ermöglicht. Die Informationen selbst kamen von anderen Stellen, die völlig unabhängig vom Suchmaschinenbetreiber existieren: Die Betroffenen selbst, die private Homepages betreiben, Institutionen, die Lebensläufe ihrer Angestellten veröffentlichen und schließlich auch Regelungen wie das Telemediengesetz, die von uns verlangen, Namen und Anschrift im Impressum zu hinterlassen.

Thomas Kliche hat im E-Mail-Interview folgendes geschrieben:

Die Einführung von neuen Überwachungspraktiken hat aber auch einen einfachen Nebeneffekt: Man gewöhnt sich dran. Man findet dann selbst Rechtfertigungen, warum es gar nicht anders geht, weil man ja selbst mitmacht.

Und auf die Frage hin, warum selbst Experten freiwillige Teilnehmer an solcher Informationsverbreitung wären:

Zeigt das nicht: Selbst kritischere Betrachter haben sich an Datensammlungen gewöhnt? Gerade die kulturell kompetenten Personen haben ja auch – wie Ihre Beispiele belegen – viel Nutzen von der Menge an leicht zugänglichen Unterlagen und Fakten.

Letztendlich hilft uns Google nur, die Informationen, mit deren Preisgabe wir ja doch gewisse Zwecke verfolgen, einfacher aufzufinden. Mit einem großen Vorteil: Google zeigt uns schnell und bequem, wie viel wir von uns selbst preisgegeben haben. Verfügbar haben wir sie selbst gemacht und es stört uns immer weniger, immer mehr Informationen herauszurücken.

“Wenn ich es nicht tu, macht es ein anderer” ist ein Satz, der häufig zitiert wird, um seine Handlungen zu rechtfertigen. Ich halte diesen Satz für überaus fragwürdig, jedoch trifft er in diesem Fall zu. Das Interesse an Informationen ist da, deswegen wird auch jemand danach suchen; in diesem Fall ist das Google. Das ganze WorldWideWeb ist schließlich zum Austausch von Informationen geschaffen worden.

Natürlich ist Google auch ein Unternehmen, das weiterwachsen, Geld verdienen, Konkurrenten verdrängen und die Aktionäre glücklich machen, die, wenn die Unternehmensführung von ihren geldgierigen Zielen abkommt, diese wohl skrupellos durch eine mit weniger Idealismus und Gewissen ersetzen würde. Deswegen wird der Nutzer dazu ermutigt, seine Kalender, Adressbuch, E-Mails und Dokumente ebenfalls bei Google abzulegen, auf dass sie durchsucht werden können. Jedoch habe ich bei noch keiner Google-Suche E-Mails, Kalenderdaten oder Kontaktinformationen anderer Personen gefunden. Ich halte Google nicht für schlimmer als jedes andere Unternehmen, das versucht, Geld zu verdienen und am Markt zu bestehen.

Trotzdem werden vermehrt Stimmen laut, die eine Abkehr vom Suchmaschinenbetreiber fordern. Folgendes Gedankenexperiment: Angenommen, es gäbe Google nicht mehr. Was würde sich ändern?

Zuerst einmal wären wir eines sehr mächtigen Werkzeuges beraubt, das es uns erlaubt, anhand weniger Stichwörter relevante Informationen zu finden. Man mag argumentieren, dass es andere Suchmaschinenbetreiber gibt. Diese würden jedoch, wenn sie Ersatz für Google sind, ebenso wachsen und eines Tages abgeschafft werden.

Für die Informationen im Internet bedeutet das gar nichts. Wie oben schon angedeutet, ist es nicht Google, der die Informationen produziert. Es sind die Internetnutzer. Und die würden mit der Suchmaschine nicht verschwinden. Zwar wäre das Auffinden erschwert, im Sinne des Internets wird es aber prinzipiell immer möglich sein, dieselben Informationen zu erhalten. Wer gefunden werden möchte, verlinkt sich und wer seine Seite geheim halten möchte, kann dies auch heute schon tun. Ohne Link wird auch Google diese Seite nicht finden.

Kommen wir also zu dem Schluss, dass Google die Informationsflut weder verursacht noch fördert, sondern wir es selbst sind, die die Informationen in den öffentlichen Raum werfen. Alles, was Google tut, ist uns beim Suchen und Finden zu unterstützen – und uns einen Spiegel vorzuhalten, der zeigt, wie viel wir letztendlich preisgegeben haben. Darüber mag man verärgert sein, aber nur mit sich selbst. Die Einschränkung von Google beseitigt nur da Symptom, nicht aber die Ursache.