Viel Glück Me.dium

http://denver.bizjournals.com/denver/stories/2008/07/21/story9.html

Me.dium macht jetzt Google Konkurrenz:

"What we show you is what people are interested in and find useful". Wenn sich das nicht nach Google anhört.

"We don’t think we’re going to take Google out", na dann.

Früher hat Me.dium die Leute angezeigt, die auf "verwandten" Webseiten gesurft sind. Also nicht nur auf der gleichen Domain, wie weblin, RocketOn, Skabble, sondern auch Seiten mit ähnlichem Content. Ich gebe zu, dass mir das schon immer zu komplex war. Content crawlen und den Inhalt herausfinden, dann Inhalte assoziieren ist eine schwierige Sache. Das ist ziemlich genau das was Suchmaschinen machen und sicher nicht das was eine kleine Firma gut kann. Wenn man wie Me.dium jetzt das Surfverhalten seiner User dazu nimmt, kann das sicher helfen. Aber wer glaubt denn, das Google das nicht macht? Google bekommt über ziemlich viele GAnalytics Tags das Surfverhalten und wer auf Suchergebnissen klickt sagt Google auch was gut ist. Das Surfverhalten dass Me.dium bekommt ist im Vergleich dazu vielleicht etwas besser und vollständiger, aber vermutlich nicht so viel besser, dass man die Suche ernsthaft besser machen kann als Google.

Me.dium bekommt etwa die Daten, die auch Alexa hat. Alexa hat auch ein Search Produkt, Alexa: "Alexa has taken search and browse to the next level and made it more complete, more relevant and more useful." Natürlich verwendet Alexa die Daten, die die User "nur zu rein statistischen Zwecken" schicken auch für die Suche. Und hat man schon mal von Alexa Suche gehört? Kann ja sein dass sie Google aussticht, aber so bekannt ist sie nicht obwohl Alexa schon seit 10 Jahren auf dem Markt ist. Alexa gehört zum Web-Urgestein.

Warum glaubt Me.dium Alexa und Google Konkurrenz machen zu müssen. Der Search-Markt ist sowieso gesättigt (oder zumindest eng). Microsoft versucht sich da seit Jahren mit viel Geld. Ich glaube Me.dium sollte lieber in Konkurrenz zu weblin, RocketOn, Skabble, usw. bleiben und sich um 100 Mio. neue User auf einem noch nicht gesättigten Virtuel Presence Markt schlagen.

Mal von Marktchancen abgesehen, finde ich es immer noch bedenklich, dass Firmen das Surfverhalten der User verfolgen und alle URLs mitlesen. Das macht Alexa schon immer so, Me.dium jetzt auch, Google "nur" auf den eigenen Seiten und da wo Web-Admins ein Analytics-Tag einbinden, Facebook hat sich mit Beacon, gerade eine leichtrote Nase geholt. PMOG, RocketOn, Skabble natürlich auch.

Aber ich bleibe dabei: Web-URLs von Usern sollten den PC nicht verlassen. Zumindest nicht für den Basisdienst. Wenn User/in will, dass das Surfverhalten FÜR IHN/SIE verwendet wird, dann ist das was anderes, aber Web-Dienste, die nur auf dem Übertragen von URLs basieren, bereiten mir Unbehagen. Das muss auch anders gehen. Man kann doch nicht Leuten eine Toolbar unterschieben nur damit man an alle URLs kommt, die sie absurfen.

Naja, trotzdem viel Glück Me.dium

Nachtrag: Anscheinend ist das auch noch anderen aufgefallen. Hier ein Vergleich Google, Cuil, Me.dium bei dem Me.dium sogar deutlich vorne liegt.

Layered Social Virtual Worlds

http://www.personalizemedia.com/the-avatars-take-over-the-asylum-layered-social-virtual-worlds/

Schöner neuer Name: Layered Social Virtual Worlds.

Web 1.0: Push, Web 2.0: Share, Web 3.0: live. Wenn mich mein Gefühl nicht trügt, könnte die 3 auch 3D bedeuten.

RocketOn ist Weblin

Mehr zum Thema was-was-ist-und-was-was-nicht-ist: RocketOn ist Weblin. Weblin ist RocketOn. Beide machen Avatare auf allen Webseiten, zwar mit unterschiedlichen Technologien, Protokollen und mit verschiedenem Fokus, aber wenn es eine ernsthafte Konkurrenz gibt, dann ist das RocketOn.

Mit anderen Worten: beide machen virtuelle Präsenz im Web. Ob hier jemand jemandes Killer ist, ist schwer zu sagen. Das Web hat 1000 Mio. User. Wenn nur 10% davon irgendwann virtuelle Präsenz machen, dann sind das 100 Mio. potentielle User. Wer die alle bekommt wissen wir noch nicht, aber wenn RocketOn wiederum 20% Marktanteil gewinnen kann, dann sind das 20 Mio. Aber was ist wenn Google 50% bekommt mit einem Produkt das sie noch nicht haben? Dann bekommt RocketOn "nur" 10 Mio. User. Das gilt auch für die Mitbewerber. Der Verdrängungswettbewerb um Marktanteile im Genre virtuelle Präsenz geht bei 10 Mio. User los. Das sollte einigen zu denken geben.

Ausserdem: es gibt auch mehrere Browser und mehrere Instant Messenger. Es gibt mehrere Autohersteller, Blogsysteme, Betriebssysteme. Was ist der USP von MSN gegenüber ICQ? Die Frage kann man nicht schlüssig beantworten. Virtuelle Präsenz ist ein gigantischer Markt. Wenn es "normal" wird präsent zu sein, wenn 10% der Web-Bevölkerung mitmachen, dann teilen wir uns gerne die 100 Mio. User mit RocketOn. So wie ICQ mit MSN teilt und gut davon lebt. Von GTalk, Yahoo Messenger und anderen mal gar nicht zu reden.

Weblin hat eine gute Chance seinen Teil zu bekommen, weil es

offen, verteilt, sicher

ist.

1. weblin ist das offene System. Das fängt beim Avatare Uploaden und selbst Gestalten an. Geht weiter dass man komplett das Aussehen selbst bestimmen kann und dass Communities und Virtuelle Welten das Web-Aussehen ihrer User in weblin selbst bestimmen. Bis dazu, dass Webseitenbetreiber selbst Chaträume einrichten können, dort selbst moderieren und ihr Hausrecht ausüben können.

2. weblin ist verteilt wie das Web. Es gibt Millionen Webserver, jede Firma hat ihren eigenen. Deshalb arbeitet weblin mit Millionen Chatservern und jeder kann den eigenen Chatserver selbst betreiben. Wenn man die Last von 100 Mio. Chattern verarbeiten will, dann muss das System verteilt sein wie das Web.

3. weblin ist sicher, weil es die Privacy des Users schützt. Bei anderen Systemen wird die komplette Spur beim Websurfen an deren Server geschickt. Alle URLs von den Seiten, die ich besuche werden an sie übermittelt. Im Gegensatz dazu bei weblin verlassen die URLs nicht den PC. Weblin geht in Chaträume aus denen man nicht erkennen kann wo jemand surft. Das ist sehr wichtig, wenn wir ein weltweites System machen wollen in dem Hunderte Millionen Menschen aus allen Ländern präsent sind. Völlig undenkbar, dass eine einzige Firma dieses System beherrscht und hundert Mio. Benutzer dort alle Seitenbesuche hinschicken.

Fürs Protokoll: ja, RocketOn und andere haben auch viele Vorteile. Sollen sie aber selber genau beleuchten.

Für die Nörgler: heute auch wieder Links zur Konkurrenz, wie gestern, natürlich! Irgendwann muss ich mal was schreiben zum Thema "Links sind überbewertet". Links sind für Leser zum Klicken. Wer vor allem an den Google Spider denkt, ist echt fehlgeleitet.

_happy_chatting()

Lively ist nicht Weblin

Wie inzwischen jeder mitbekommen hat, beteiligt sich Google mit Lively am 3D-Welt/Avatar-Hype. Wir sehen im Moment ein Browser-Plugin mit dem man einen 3D-Raum in eine Webseite einbetten kann. Besser gesagt: wenn man das 10 MB Plugin installiert hat, dann kann man Lively-Räume betreten, die auf Webseiten eingebettet wurden.

Damit reiht sich Google ein in eine Unzahl von ähnlichen Systemen, wobei die meisten Flash als Player verwenden, statt einer eigenen installierpflichtigen Engine. Ein klassisches MeToo. Und das von Google, wie un-innovativ.

Naja, vermutlich ist das nur der Anfang. Google hat mit Google-Earth schon eine virtuelle Parallelwelt. Da fehlen eigentlich nur die Avatare. Vielleicht ist Lively ein Weg, um sich an das Avatargeschäft heranzutasten. Wenn Google wirklich Avatare, Inneneinrichtungen und eine Ökonomie in Google-Earth bringt, dann müssen sich ein paar andere virtuelle- und Parallelwelten warm anziehen. Aber das ist es ein weiter Weg und bis dahin droht von Lively keine Gefahr.

Gefahr droht vielleicht für die anderen eingebetteten Welten, die sich nicht auf Games spezialisieren. Runescape, Habbo, usw. sind bestimmt sicher vor Lively. Multiverse, Metaplace, und viele andere gerade gestartete oder in der Entwicklung befindliche Plattformen für "einbettbare" virtuelle Welten sind eher betroffen. Obwohl auch bei denen Unterschiede bestehen und sie sich selbst nicht betroffen fühlen.

Aber es gibt da eine virtuelle Welt, die sicher nicht von Lively betroffen ist: das Web. Systeme, die Leute auf Webseiten sichtbar machen wie weblin und (ganz neu:) RocketOn machen etwas ganz anderes, als virtuelle Welten, die in Webseiten eingebettet sind.

- weblin: Avatare AUF der Webseite (= die Webseite ist der Raum) und zwar auf JEDER Webseite im Gegensatz zu:

- Lively: Raum ist in Webseite eingebettet und Avatare da drin.

Avatare auf jeder Webseite geht auf 100 Mio. Webseiten oder wie viele das Web eben so hat. Avatare in Räumen in Webseite eingebettet geht auf 10.000 Webseiten oder wie viele so etwas eben eingebettet haben. Das ist eine kleiner Unterschied.

Trennung von Memcache und Web Server

Memcache (memcached) nimmt meiner Datenbank fantastisch viel Arbeit ab. Alle Objekte sind im Memcache, kein Code greift direkt auf die Datenbank zu. Die Datenbank wird dadurch um eine Größenordung entlastet. Was die Datenbank leisten müsste sieht man dann, wenn der Cache leer ist. Dann geht alles direkt auf die DB bis der Cache wieder gefüllt (warm) ist.

Der Memcache ist ein verteilter Speicher. Er ist verteilt über mehrere Rechner. Will man keine Rechner extra für den Memcache abstellen, dann verwendet man traditionell die Webserver auch als Memcache-Server. Das heißt nicht, dass es schneller wird, weil die meisten Zugriffe nicht lokal sind, aber billiger weil man keine extra Rechner braucht. Die Webserver hat man ja sowieso. Die Standardvorgehensweise ist also: 10 Webserver hinter einem Loadbalancer. Auf jedem Webserver ein memcached. Das wird deshalb empfohlen, weil Webserver vor allem CPU brauchen (CPU bound) und der Memcache vor allem Speicher (memory bound). Man kann also die jeweils "andere" Ressource auch noch nutzen.

Soweit die Standardvorgehensweise. Tatsache ist aber, dass bei PHP/Apache basierten Webservern (LAMP!) Webserver meistens auch memory bound sind. Apache und PHP werden nämlich normalerweise im Prefork-Modus verwendet. Also viele Apache Prozesse, jeder mit einer eigenen PHP-Runtime. Bei einer großen Applikation braucht ein so ein Apache/PHP Prozess schnell mal 16 MB Speicher. Der geteilte Speicher der verwendeten DLLs fällt kaum ins Gewicht. Das sind fast alles Daten. Ein Standardserver vom letzen Jahr hat 2 GB Speicher, 2 Cores. Will man 100 Apache Prozesse laufen lassen, bekommt man 16 MB x 100 = 1,6 GB. Da bleibt nicht mehr viel für den Memcache, der auch sein 1 GB pro Rechner haben sollte. Schließlich sind ja 1 Mio. User und zig Millionen Objekte im Cache. Dieses Jahr sind es 4 GB und 4 Cores, aber man erwartet auch 200 Prozesse pro Rechner, also auch nicht besser. Apache und Memcache konkurrieren um den Speicher.

Und es wird noch schlimmer. Apache und Memcache haben in der Standardkonfiguration unterschiedliche Verfügbarkeitsanforderungen. Webserver hinter dem Loadbalancer können ab und zu mal ausfallen. Der Loadbalancer merkt das schnell und nimmt sie aus dem Lastverteilungsverbund. Alle Daten, alle Sessions sind im Memcache und damit stets transferierbar. Aber: vom Memcache-Verbund darf kein einziger Rechner ausfallen. Selbst wenn man das schnell merkt und ihn aus dem Verbund nimmt, bedeutet der Ausfall eines einzigen Memcache-Servers einen 50% Cache-Flush. Memcache-Clients berechnen aus dem Key und den verfügbaren Memcache-Servern auf welchem Server die gefragten Daten liegen und holen sie direkt dort. Fällt ein Server aus, dann ändert sich die Zuordnung der Keys zu den Memcache-Servern. Die Daten bleiben dort gespeichert, aber die Clients finden sie nicht mehr und nehmen an, dass sie nicht da sind. Es gibt alternative Zuordnungsalgorithmen, die verhindern, dass sich alle Keys umsortieren. Das ist bitter nötig in großen Memcache-Clustern (Facebook: man spricht von 800 Rechnern mit viel Speicher). Denn dann fällt immer einer aus oder es kommt einer dazu.

Aber trotzdem reicht das nicht, denn Webserver sind manchmal überlastet und fallen für den Loadbalancer effektiv aus. Wenn auf dem gleichen Rechner ein memcached läuft und der auch nicht mehr antworten kann, dann fällt ein Teil (20% oder 10%) des Caches aus. Das treibt die Datenbank sofort zu Höchstleistungen und propagiert das Überlastproblem vom Frontend-Rechner zur DB. Das kann schnell die Performance des Gesamtsystems zerstören. Denn braucht die DB 1 h bei leerem Cache um den Cache zu füllen, dann führt der Ausfall von 1 aus 5 Memcaches immerhin zu 1h / 5 = 12 Minuten Überlast auf der DB. Das hört sich nicht gut an, denn eigentlich ist es das Ziel überhaupt keine Spannungssituationen zu erzeugen bloß weil ein Webserver ausfällt.

Webserver arbeiten viel mit der Festplatte. Das ist im high-performance Bereich auch zu vermeiden, aber ist trotzdem Standard im Medium-Segment. Geht die Festplatte kaputt steht der Webserver. Memcache arbeitet nur mit Speicher, überhaupt nicht auf der Platte. Steht die Platte kann er weiterarbeiten. Es ist unsinnig den Memcache von der Festplatte des Webservers abhängen zu lassen. Eigentlich sollte der Memcache-Server vom Netz booten und ohne Platte arbeiten. Ein Teil weniger was kaputt gehen kann, und zwar das häufigste.

Webserver und Memcache haben sehr unterschiedliche Profile und sollten deshalb nicht die Rechner teilen. Webserver (sollen nicht, aber) dürfen ausfallen, deshalb Software RAID-1. Memcaches (tun es, aber) dürfen nicht ausfallen, deshalb entweder RAID-Controller, damit die Platte im Betrieb getauscht werden kann oder gar keine Platte. Webserver so bemessen, damit sie CPU und Speicher Last tragen können. Separate Memcache-Server bemessen, so dass alle zusammen alle Daten der Applikation speichern können, die innerhalb der TTL der Cache-Items anfallen.

happy_coding()

Danke Adobe für TCP Port 843

Vor ein paar Tagen den ersten erntzunehmenden Konkurrenten von weblin entdeckt: ROCKETON. Der ROCKETON ist im in Flash 9 programmiert und ROCKETON schreibt, dass man Port 843 outgoing öffnen muss.

Von der Hilfeseite: "Since our application uses Adobe Flash, we must abide by their security policy. In order for Adobe Flash to work in a multiuser environment, you must have port 843 open. Please ask your system administrator to make sure port 843 is not being blocked."

Auf Port 843 liegt ein Policyfile für Flash. Die Datei muss jeder anbieten, der mit Flash 9 Socketverbindungen zu anderen Hosts benutzen will. Das Policyfile muss auf dem Server liegen zu dem verbunden werden soll und zwar auf Port 843. Nu ist mir nicht ganz klar warum ROCKETON Socketverbindungen benutzt, da ROCKETON eigentlich HTTP-long-polling verwendet, aber sie werden es schon wissen.

Was mich aber wieder einmal gewundert hat ist der Port 843, den Adobe für Flash 9 erfunden hat. Klar, mit Socketverbindungen kann man allerhand Unfug treiben. Java benutzt ja auch das für Security eigentlich ungeeignete DNS, um Applets nicht auf beliebige Adressen verbinden zu lassen. Dass das nur ehrliche und hart arbeitende Normalbürger behindert, aber nicht echte Schlimmfinger ist inzwischen bekannt (Stichwort: DNS Rebinding Attacks). Flash dagegen läßt sogar Verbindungen zu anderen Rechnern zu, aber nur wenn dort das Policyfile verfügbar ist. Leider liegt das Policyfile nicht auf den üblichen Ports 80 oder 443. Diese Ports sind meistens offen, haben schon einen Webserver und man müsste nur eine Datei hinlegen. Nein, man muss extra ein Programm laufen lassen auf Port 843, das die Datei hergibt. Und noch schlimmer: der Port ist in Firmen-Intranets meistens nicht offen. Das heißt, Software in Flash 9, die im Labor und bei normalen Benutzern geht, versagt typischerweise im Büro von Kooperationspartnern und Journalisten. D.h. immer wenn man im Business-Development jemand eine Vorführung machen will geht es nicht. Zuhause aber schon. Danke Adobe.

Warum ist das so. Warum nicht Port 80? Vermutlich ist es Adobes Absicht, dass Socketconnections im Firmenumfeld nicht gehen, damit Attacken, wie DNS Rebindung und Portscanning nicht funktionieren. Nette Idee, um private Rechner von Firmenrechnern zu unterscheiden, aber irgendwie auch ganz schön doof und vor allem ziemlich nervend, wenn man mit Flash tolle Sachen machen will. Ja, sie können es machen. Flash gehört ihnen und wir müssen es ja auch nicht benutzen. Aber irgendwie habe ich das Gefühl, dass es bessere Schutzmechanismen geben muss, als DNS, Stringvergleiche und gesperrte Ports.

Weblin Whiteboard oder: User finden alles

Jemand hat das Whiteboard in weblin entdeckt und User erschreckt. Das Whiteboard kann einfache Grafiken auf Webseiten produzieren, die dann alle im Raum sehen. Kommt man zu spät in den Raum, sieht man es nicht, weil es nur wie Chat als Message vorbeisaust. Wenn es keinen Protokollbot gibt, der die Messages speichert und wieder abspielt, sind die Whiteboard-Messages transient (flüchtig). Die Grafik liegt über allen anderen Fenstern, so dass man den Eindruck bekommt, dass sie auf allen Seiten ist. Ist sie aber nicht, sondern nur in dem Raum wo sie gemacht wurde. Übrigens wenn es nervt: Rechtsklick auf den Rand, oben steht wer es gemacht hat und unten steht "Löschen".

Der Whiteboard Code ist in weblin noch drin und eigentlich nicht erreichbar. Aber natürlich zu Debugzwecken dann doch. Das zeigt wieder mal, dass User alles finden. Security by Obscurity hat keine Chance.

Es gibt einfach so wahnsinnig viele User, die sich so engagiert mit dem Thema befassen. Die kennen das System oft besser als Entwickler. Entwickler benutzen das System weniger, als User. Natürlich kennen Entwickler den Teil den sie gemacht haben sehr gut, aber Entwickler sind trotzdem meistens keine Poweruser. Entwickler kennen die Theorie, User die Praxis. Entwickler programmieren einzelne Features und bedenken dabei manchmal auch Zusammenhänge. Aber User erkennen Muster im Verhalten von Software, die die Entwickler nicht explizit programmiert haben. Vielmehr sind entstehen Wechselwirkungen mehrerer Features, die sich durch sehr intensive Beschäftigung zu einem Muster verbinden.

Das gilt genauso für Games, wo diese Bedienungsmuster im High-End Bereich ein wichtiger Teil des Gameplays werden. Das gilt auch für alle anderen Programme, wie in diesem Fall weblin, mit denen sich User intensiv und lange beschäftigen. Manche Leute lernen das Programm einfach durch intensive Benutzung seiner Features, andere durch Analyse von Code, Protokoll und Reaktionen.

Weiter so Leute, zeigt den Entwicklern was "Wisdom of the Crowds" heisst.