20. September 2008

Tscheljabinsk Smiley auf Google Maps

Die Bewohner der russischen Stadt Tscheljabinsk haben berechnet, wann der Satellit QuickBird, der Fotos für Google Earth und Google Maps macht, ihre Stadt überfliegt. Sie bildeten einen riesigen Smiley. Damit viele Leute kommen wurde ein Volksfest mit Band organisiert und alle Zuschauer haben sich gelbe Capes übergezogen.

Und es hat tatsächlich geklappt. Das Foto ist auf Google Maps angekommen. Es sieht so aus, als ob sich die Verantwortlichen bei Google hier ganz besonders schnell waren. Normalerweise stellen sie neues Material nicht so schnell online. Vielleicht sind sie selbst begeistert von der Idee, dass eine ganze Stadt sich so ins Zeug legt.

Wenn das mal keine Nachahmer findet.

Chelyabinsk: Giant Smiley on Google Maps

Citizens of the russian town Chelyabinsk calculated when the satellite QuickBird would cross above their city. QuickBird takes images for Google Earth and Google Maps. They created a giant smiley face. A rock concert on the main square attracted many people and everyone got a yellow cape.

And it worked. The image is on Google Maps. It looks like someone at Google was quicker than usual to put up the new data. Maybe Google likes the idea, that an entire town works hard to get its 15 minutes of fame on Google Maps.

To the right is a screenshot of the Chelyabinsk city center. There are also images taken at the event.

( The figure in the lower left corner is my Weblin )

Update: It looks like they restored the original image. Maybe they do not want to encourage copy cats. After all they are trying to show a realistic view of earth and not a collage of events.

13. September 2008

LHC : Schwarze Löcher überbewertet

Eine kurze Zusammenfassung dieser Sache mit den Schwarzen Löchern beim LHC.

Beim LHC wird mit Energiewerten gearbeitet, die 1000 mal höher sind als beim Vorgänger LEP. Es kann sein dass dabei schwarze Löcher erzeugt werden. Das ist aber kein Grund zur Panik weil...

...wenn der Physiker sagt "kann sein" nicht heisst das welche erwartet werden. Es ist nur nicht 100% ausgeschlossen weil die Physikerin nie was falsches sagen will.

...die Energie zwar höher ist als bei LEP, aber wenn daraus Materie erzeugt wird ist das immer noch verdammt wenig. 100 mal weniger als man für eine Bakterie braucht. Man braucht also keine Angst haben davon eingesaugt zu werden, weil man die Anziehungskraft einer Bakterie nicht merkt. Man merkt ja nicht einmal den Mount Everest, wenn man daneben steht (also von der Gravitation her meine ich).

...ein schwarzes Loch mit dem Gewicht einer Bakterie so unglaublich klein ist. Die ganze Erde wäre als schwarzes Loch nur 1 cm gross. Verkleinert man eine Bakterie entsprechend, dann ist das Ergebnis viel viel kleiner als ein Atomkern. Das heisst es fällt einfach zwischen den Atomen in der Erde durch bis zum Mittelpunkt im freien Fall. Es braucht eine halbe Stunde bis zur Mitte und fliegt dann weiter bis auf die andere Seite. Nach zwei Stunden kommt es wieder hier vorbei und hat keinem weg getan. Einfach zwischendurch gewitscht, denn was für uns feste Materie ist ist eigentlich ziemlich leer. Wenn wir die Hand auf den Tisch legen, dann spüren wir den Gegendruck der Elektronenhüllen. Zwischen Elektronenhülle und Atomkern ist aber viel viel NICHTS wo das Bakterien-Black Hole durchpasst. Und für ein Bakterien-Black Hole ist sogar der Atomkern fast NICHTS. Nur wenn es ein Proton head-on trifft kann es das fressen. Das ist aber sehr selten.

...selbst wenn es ab und zu einen Atomkern frisst auf dem Weg durch die Erde dann wächst es trotzdem sehr langsam. Es braucht 3 Milliarden Jahre, um ein (in Zahlen: 1) Gramm Erde zu verputzen. Und selbst dann ist es ungefährlich, weil die Anziehungskraft von einem Gramm auch nicht groß ist. Schon mal jemand von einem ml Wasser eingesaugt worden?

...es das nach der Hawking-Theorie das alles gar nicht machen kann. Je kleiner ein schwarzes Loch ist, desto schneller "verpufft" es. Große schwarze Löcher sind sehr stabil, wenn sie die Masse der Sonne oder der Erde haben. Aber wenn sie nur so viel wiegen wie ein großer Lastwagen, dann leben sie nur eine Sekunde. Ein Black Hole mit der Masse einer Bakterie verpufft viel schneller. Gerade wurde es geboren und beginnt langsam zum Erdmittelpunkt zu fallen, aber bevor es den Boden erreicht, ZAPP, kaputt. Es endet als Teilchenschauer im Detektor und bringt dem Physiker, der gerade hinschaut einen Nobelpreis. Immerhin - wer kann das von sich sagen.

also: Don't Panic.
in Memoriam D.N.A.


17. August 2008

Big and Bigger Systems

I started to compile a list of guidelines for developing big systems. So, what is a big system?

  • "Big" means 5k - 100k concurrent users.
Of course, there are even bigger systems. There is also
  • "Massive" 50k up to 1 Mio. concurrent and
  • "Mainstream" 500k up to 10 Mio. concurrent and beyond.
The guidelines are for the smallest one the of 3 noteworty categories: "Big". This is the category I am experienced with. 10 or 20k concurrent is significantly different from normal/sparetime/hobby systems. But it is still conventional technology (e.g. on standard LAMP). I can imagine what needs to be done to get a massive system up and keep it running. ButI have never done it, yet. I can only dream of a mainstream scale system, especially a unique and not sharded one (see below).

Examples:
  • "Big": Xing, major online newspapers, Wikipedia, many browser games,
  • "Massive": Second Life, EVE-Online (barely), Runescape (I guess), Habbo, Facebook,
  • "Mainstream": WoW (barely), major IM networks (QQ, ICQ, MSN), Google search, mobile networks.
In other words:
  • "Big" ranges from "substantially over the top of your single server" to "the complete cluster would appear in the Top 500 Supercomputers list". EVE-Online is at the top of "Big" by sheer numbers, but it is on the brink to "Massive" because of its complexity. Xing: more than 10k click around on the web site at any time, sometimes twice as much.
  • "Massive" is really large. Think about thousands or ten times more servers. That's a decent farm. Second Life is at the lower end. Their server numbers are a bit high for the user count, because of their architecture. Facebook is somwhere in the middle with 50 TB cache memory alone. This number is already 20,000 times more than your PC and growing. We are talking about the large web services, companies with 10 B market capitalization. These are "Massive". The big guys.
  • "Mainstream" is unthinkable. Can you imagine half a million servers? If you stack them, they scratch the International Space Station. If you plan a system like this for everyone, then better avoid the hazzle and make it distributed like the Web. It's made for 10% of the world population (registered users not concurrent). There are few such systems on the planet. Few people managed to build in this order of magnitude. I am sure they grew into it with the system. Nothing that you can buy.
Of course there are differences in complexity between a static web site and an MMOG. A static web site, e.g. a newspaper may need much less resources for 10k concurrent readers, than a vitual world for 10k concurrent players. Comunication in an IM network is very different from a MMOG. MMOGs enter the "Massive" category earlier than browser games.

But there are also factors, which make the complexity similar or at least in the same order of magnitude.
  • As an example, 10k HTTP/HTML readers make more network connections (easily 10k conns per sec.) than 10k players (100 conns per sec. when people log in).
  • The data delivered may be in the same order of magnitude. Lets face it: a web site consists of min 100 items and active readers fetch 0,1 pages per second. This makes 10k x 0,1 x 100 = 100k items/sec. I doubt, that MMOGs deliver more than 100 items/sec to clients. This is 10 times more than what the web server does, but most MMOG items are just IDs of data pre-installed at the client. The web-items are all completely transferred. This reduces the difference. SecondLife transfers really many items by data. For a virtual world it is still an exception and it shows in the bad performance when discovering new areas.
  • Then, there is a stupid reason, why web servers may feel the same load as MMOG servers: average web server technology is much worse, especially if they use scripting languages. Nobody would make MMOG servers in PHP. They are compiled code, C++, C#, compiled Java, compiled Python. But many "Big" web sites run on (uncompiled) byte code. Better than the script, but still byte code.
  • Also, apart from good and bad technologies, there is good and not so good (=stupid) code. This happens to all types of systems and can make an MMOG more responsive than a web site at the same number of users.
  • Across all types of services, some are sharded, some are unique worlds. EVE-Online is unique, which means everyone can play with everyone. WoW is sharded into 1,000 (?) servers of up to 3,000 (?) concurrent players. Your friend is on a different server? you do not even chat to him. Sharding largely reduces communication and DB load. If shard=host then communication overhead disappears. A DB per shard allows for 100 or 1000 times less DB load per instance. This helps a lot.
  • After all, each category covers an order of magnitude. There is much room for "small" or "large" inside a category.
All in all, the classification into "Big", "Massive", "Mainstream" works.

Distributed systems do not really count here. This is about operating the resources required to support concurrent users. E.g. the Web is not operated by a single entity (though you could count the DNS). The Skype network has a (cool) architecture, that lets Skype, the company manage the network without the need to provide all required resources. Skype is also not an issue here. But most systems are operated by someone with a server farm and this is about what these people do.

So, these lessons are for "Big" systems. Actually primarily for web servers but also some messaging issues and general remarks. Some lessons are obvious, some are obvious in hindsight, some are not so obvious, some may be interesting even if you are one of the few (thousand) architects of big systems worldwide. Read the (far from complete but growing) list of lessons here.

9. August 2008

RocketOn Adds Monsters, Quests for Launch - GigaOM

http://gigaom.com/2008/08/08/rocketon-adds-monsters-quests-for-launch/

RocketOn wird am 15. September starten, mit "Monstern und Quests". RocketOn positioniert sich anscheinend für Gamer, die wie in anderen virtuellen Welten Quests machen, Monster bekämpfen und ihre Pets kämpfen lassen. Es gibt 2 virtuelle Währungen: die eine kann man gegen harte Währung kaufen, die andere verdient man sich durch Aktivitäten (genau wie bei wie bei weblin!).

Während weblin mehr parallel zum Web Surfen läuft, aktiviert man RocketOn und kann dann nicht mehr mit der Webseite interagieren. Vielleicht ändert sich das ja auch noch bis zum Start.

RocketOn orientiert sich eher am Gamer, weblin ist eher allgemeine Präsenz und Avatarchat auf dem Web und weniger zielgruppenspezifisch. GigaOM geht sogar so weit zu behaupten, dass sich weblin an eine ältere Zielgruppe wendet, als RocketOn.

Ein zartes Anzeichen, dass sich das Genre diversifiziert. Eine Vorbedingung für die Entstehung eines Massenmarkts, (aber natürlich keine Garantie).

Insgesamt sehr cool. Weiter so.

8. August 2008

Layered Virtual Worlds

http://www.virtual-presence.org/news.html?Title=Overlay_Virtual_Worlds

Hier ein Kommentar zu "Layered Virtual Worlds" (englisch) auf www.virtual-presence.org.

Mal richtig "selbstreferentiell". Manche nennen es selbstreferentiell, andere nennen es Trackback. Dafür aber umso schöner mit weblin Publisher fix hergestellt. Ehrlich, wenn ich Avatare doof fände, ich würde weblin für den Publisher laufen lassen. Wenn es nicht läuft mache ich weblin sogar an, um was zu bloggen. Wer hätte das gedacht.

6. August 2008

Neuer Server

Endlich mal abends Zeit gefunden den Server aufzusetzten. Der übliche Hetzner minimal-bootstrap, mit RAID1, dann:
- firewall
- apache
- php, memcache, apc
- minimales Hardening
- SSL Zertifikat
- default Virtual Server nur über https
- mysql, phpmyadmin
- ejabberd
und Domain Umzug im DNS.