Zwei Dumme ein Gedanke

Bartholomew Gallacher 27. Dezember 2012 8 Kommentare

Khufu Greymoon (der frühere Name war falsch!) hat sich heute hingesetzt und eine Forenbaustelle auf Basis von SMF als Software erschaffen, das nach meiner Info bereits für den Publikumsverkehr offen ist, und so sieht das Ding ausKhufu

Und so sieht bisher meine eigene Baustelle auf Basis von myBB aus:

Natürlich bin ich da völlig voreingenommen und finde mein Template tausend mal augenschonender und besser lesbar, außerdem habe ich nicht vor, irgendwelche Werbebanner von Virwox, Google Ads und sonst noch zu schalten. Weiß auf Grau ist einfach nur noch retro und dazu noch rot – nein danke.

So oder so – bei beiden hapert’s beim Namen. „Second Life Forum“ ist bei mir ein ganz dummer Projekttitel, weil mir bisher nichts besseres eingefallen ist und „SL-Inside“ beim anderen als Name ist auch schlecht, weil Avameet vor seiner Umbenennung Slinside hieß und das einfach nach wie vor zu Verwechslungen führen könnte.

Werft endlich die Skriptscanner raus!

Bartholomew Gallacher 10. Dezember 2012 2 Kommentare

In Slinfo.de gab’s mal wirklich einen interessanten Thread zum Thema Skriptscanner und deren Unwirksamkeit.

Das Fazit in Kurzfassung ist das folgende: die Anzahl der Skripte pro Avatar sagt absolut nichts darüber aus, welchen Einfluss diese auf die gesamte Simleistung haben werden.

Und selbst wenn jemand ein Killerskript schreibt, das Rechenleistung wie Sau zieht und das zigfach kopiert – schaut euch hier mal das Beispielskript von Shirley an – dann bringt das die Sim immer noch nicht aus dem Tritt, sondern sie läuft fluffig geschmeidig weiter, weil inzwischen Linden Lab offensichtlich intern die Abarbeitung der Skripte so gut geregelt bekommen hat, dass die Sim davon gänzlich unbeeindruckt einfach stur und gut weiter läuft.

Also, liebe Simbesitzer, werft endlich eure überflüssigen Skriptscanner ein für allemal raus, denn sie bringen absolut rein gar nichts – eure zukünftigen Besucher werden es euch danken!

Da liegt sie nun, die Hoffnung der Meshfreunde und ist doch noch nicht das, was man sich erhofft hat…

Bartholomew Gallacher 6. Dezember 2012 0 Kommentare

Dieser obige Gedanke kam mir, als ich bei Maddys Wochenumschau die Neuigkeiten von Nalates Urriah in Bezug auf den Mesh Deformer gelesen habe.

Nun, was ist geschehen?
Zunächst einmal die gute Nachricht: es wird nach wie vor am Mesh Deformer mit Hochdruck gearbeitet und die Entwicklung geht offenkundig weiter, auch wenn man davon in der Öffentlichkeit momentan weniger mitbekommt, so stehen die Räder da dennoch nicht still. Das ist schon mal eine gute Sache, vor allem wenn man auch bedenkt, wie lange dieses Feature nun bereits in der von SL-Bewohnern finanzierten Entwicklung steckt! Wer zahlt, der will schließlich auch irgendwann etwas dafür sehen, und man sieht es auch!

Wo liegt das Problem?
Das Problem liegt nach Nalates Urriah darin, dass der sagenhafte Mesh-Deformer momentan vor allem auf älteren Rechnern das Tempo einer Weinbergschnecke vorlegt im Bereich seiner Berechnungen.

Die Avatare werden nacheinander, also seriell, abgearbeitet und die Kalkulationen sind sehr umfangreich. Die Zeit, die sich dann ein älterer Rechner gönnen soll bis er mit Deformieren fertig ist, soll im Bereich von mehreren Minuten liegen und das ist einfach für ein fluffiges SL-Erlebnis viel zu lange.

Wer neuere Rechner hat, der soll das Problem nicht haben. Nun wird darüber spekuliert, dass das Problem auch daher rühren könnte, dass der Deformier-Thread im Viewer eine recht niedrige Priorität habe und ein Anheben diese das Problem beseitigen könne. Ich bin mir sicher, das wird ein TPV-Entwickler sehr flott ausprobiert haben.

Der andere Vorschlag, der gefallen ist, ist dass das Deformieren auf SL-Servern stattfinden solle wie in Zukunft auch das Texture Baking für die Avatare, so dass die Clients damit nichts mehr zu tun haben. Die Wahrscheinlichkeit aber, dass dies realisiert werden wird, ist dann doch recht gering.

Was bleibt?
Es klingt alles schlimmer, als es in Wirklichkeit ist. Ich bin mir sicher, der Deformierer wird nun erst einmal getuned werden und man wird schon versuchen Mittel und Wege dafür zu finden, seine Arbeitsweise zu beschleunigen. All das wird noch ein wenig Zeit und Arbeit erfordern, aber findet sicher schon statt und dann irgendwann wird er vielleicht doch einmal Ready for Prime Time werden. Im Moment ist er es offenkundig als Baustelle jedenfalls noch nicht.

Und wer dann eben einen älteren Rechner haben sollte, der wird dann unter Umständen eben Pech haben. Das mag zwar hart klingen, aber so ist das Leben.

Inventarexport-Dienstprogramm für Opensim angekündigt

Bartholomew Gallacher 16. November 2012 0 Kommentare

Auf der Mailingliste „Opensim Users“ ist seit gestern durch eine Ankündigung von Snowcrash Short (nachzulesen hier) eine denkbar lebhafte Diskussion entbrannt.

Worum geht es? In Kurzfassung darum: Snowcrash Short hat angekündigt ein clientseitiges Tool zur Dezentralisierung von Benutzerinventaren zu schreiben, das er in zwei Wochen als Opensource veröffentlichen will.

Die Idee dahinter ist, dass das Inventar und die dahinterliegenden Assets vom Benutzer kontrolliert werden könnten. Es sei für ihn frustrierend, in X Grids X verschiedene Inventare zu haben. Zu diesem Zweck habe er ein Tool geschrieben, das das Inventar in einen lokalen Cache kopiert und dann in ein anderes Grid kopieren kann. Dabei sei es so geschrieben, dass es die Second Life Richtlinien für den Export beachte, es gäbe auch eine uneingeschränkte Version für Opensim.

Diese simple Ankündigung reichte schon aus, dass in der ansonsten recht friedlich vor sich hin dümpelnden Liste ein gewaltiges Echo ausbrach.

Beispielsweise meldete sich Melanie Thielker von Avination zu Wort und findet gibt ihm folgenden Rat:

My advice is to consult a lawyer at your place of residence, as in some jurisdictions producing software capable of performing these actions is a criminal offense.

IMHO, open source is a very bad idea for this type of software.

Nun, auch eine Meinung, nur ist sie damit mal eben fünf Jahre zu spät dran. Warum? Ganz einfach darum, weil das Übertool für den Inventarklau seit über fünf Jahren bereits Opensourcesoftware ist – nämlich der Second Life Viewer selber. Da ist alles drin, was man jemals dazu brauchen wird und das stört da inzwischen keinen mehr.

Natürlich kann man darüber diskutieren, ob man die Schranken für den Export senken sollte oder auch nicht, nur: wer unerlaubt kopieren will, der tut das so oder so, egal nun ob es dieses Tool gibt oder nicht. Das alleine kann kein Hinderungsgrund mehr sein, es nicht als Opensource zu veröffentlichen, sonst kann man gleich bei Stored Inventory bleiben.

So oder so jedenfalls eine interessante Lektüre und man sieht, dass auch die OS-Community zumindest dort für solche Themen sehr sensibel geworden ist und nicht längst alles offen begrüßt, was irgendjemand schafft.

Was bleibt? Die Ankündigung, dass das Tool kommen wird und dann wird man weiter sehen.

Der parametrische Mesh-Deformer erneut beleuchtet

Bartholomew Gallacher 24. Oktober 2012 0 Kommentare

Nun ist es bald schon ein Jahr her (28.10.2011), seitdem die SL-Community 5,555 US$ ausgab, um durch Karl Stiefvater eine Lösung für das Problem mit dem automatische Anpassen der Meshes an die jeweilige Avatarstruktur in Auftrag zu geben.

Das Tempo seitdem war mal schneller und mal langsamer, Drittviewer wie Nirans bauten zuerst bei sich die jeweiligen Arbeitsfassungen des Deformers ein, und manchmal schien es als sei das Projekt auch auf der Kippe, als Oz Linden um Shapes bat aber ihm das nicht schnell genug ging.

Entgegen der ursprünglichen Befürchtungen ist die Unterstützung durch die Lindens doch recht gut gewesen, und es gab sogar einen offiziellen Project Viewer mit dieser eingebauten Technologie.

In der Zwischenzeit waren andere auch fleißig und so gibt es mindestens einen alternativen Ansatz, der auch funktionieren soll aber von dem meines Wissens außer den Ankündigungen der Macher bisher nur das Prinzip bekannt ist und man sonst wenig gesehen hat.

So oder so, der parametrische Mesh-Deformer, den viele ja als fundamentalen Bestandteil für den Durchbruch von Meshklamotten ansehen, er lässt nach wie vor eben auf sich warten, als schwebe er in Wartestellung. In der Tat sind zwar die offiziellen Kanäle recht ruhig, aber nach wie vor wird an dem Projekt gearbeitet, wie man bei Nalates Urriah nachlesen kann, momentan ist Feinschliff und Fehlerbehebung angesagt und vielleicht gibt es in einigen Wochen wieder einen neuen Projektviewer.

Bei den aktuellen Arbeiten allerdings handelt es sich um Patches von Darien Caldwell, und ob Karl die nun bei sich einbaut oder nicht und das Lab die haben will oder nicht steht auf einem anderen Blatt.

Die Arbeiten ziehen sich jedenfalls nun schon lange, länger als vielleicht manche anfangs dachten, und bisher hat man das fertige Produkt nach wie vor nicht in den Händen, weil es ganz einfach bisher diesen Status noch nicht erreicht hat.

Natürlich bleibt dabei immer noch die Frage bestehen, wieso Linden Lab eigentlich dieses sinnvolle Feature nicht von Anfang an selbst gebaut hat – genügend Manpower haben sie ja. Aber manches wissen eben nur die Lindens selber…

Kleines Update zur neuen JIRA-Regelung

Bartholomew Gallacher 11. September 2012 0 Kommentare

Sooo… nachdem die Meinungen zur neuen JIRA-Politik ein wenig auseinandergehen, noch einige Fakten: hat man nun als Entwickler noch Zugriff darauf oder nicht?

Tonya Souther von Firestorm sagt, sie habe keinen Zugriff mehr darauf. Katharine Berry dagegen sagt, sie habe aktuell sehr wohl Zugriff darauf

Wie geht das zusammen? Die Antwort darauf ist einfach: Linden Lab wird noch auch ausgewählten Entwicklern Zugriff auf das JIRA geben, genauer auf die Suche, die im Vorfeld das Contribution Agreement unterzeichnet haben. Die genauen Bedingungen werden nach Oz Linden zwar noch diskutiert, aber darauf wird es ziemlich sicher hinauslaufen nach seiner Aussage.

Ist das nun gut oder schlecht, dass sich zukünftig nur noch ein handverlesener Kreis an Auserwählten sich alle Fehlerberichte ansehen kann? Eindeutig schlecht, denn es macht die Entwicklercommunity kaputt!

Warum macht es die Community kaputt? Ganz einfach weil die Mehrheit niemals die Vereinbarung mit Linden Lab unterzeichnet hat und viele, gute Programmierer wie Henri Beauchamp das auch aus sinnvollen Überlegungen niemals tun werden.

Linden Lab schafft hier eine Zweiklassengesellschaft, die der Community nur schadet und vor allem die Entwickler von Opensim-Viewern dürften es nun schwerer haben, auch wenn ich mir nun sicher bin, dass Firestorm noch Zugriff auf den Bugtracker bekommen wird.

Was bedeutet die Reform des JIRA-Trackers genauer?

Bartholomew Gallacher 10. September 2012 0 Kommentare

Ich habe mir zu der Änderung im Umgang mit dem JIRA-Tracker noch so einige, weitere Gedanken gemacht.

Die einen sehen darin einen notwendigen Schnitt und Schritt in die Normalität. Ein Bugtracker ist schließlich zum Melden von Fehlern gedacht und nicht als Abstimmungssystem über Features, die viele nun sehr gerne hätten oder um in den Kommentaren Druck auf die Entwickler auszuüben. Aber gerade das war sehr häufig im Laufe der Zeit im JIRA geschehen, wer kennt es nicht, dass irgendjemand ein Ticket zu irgendwas eröffnete, dann den Link weiter reichte und darum bat, man möge bitte dafür abstimmen, damit Linden Lab mal den Arsch hochkriegt und das behebt? Eben!

Dafür war das System nie gedacht gewesen, andererseits ist es aber auch so, wenn man es wirklich systematisch ausgewertet hat, konnte man daraus eine Menge über die Wünsche seiner Kunden erfahren.

Also ist das aus Sicht Linden Labs ein Schritt in die richtige Richtung, diese Unkultur im Bugtracker zu unterbinden, für die er niemals gedacht gewesen ist.

Aber das greift dann eben doch ein wenig zu kurz. Man hätte nämlich es so machen können, dass Bugs sehr wohl noch für jeden öffentlich sichtbar sind, aber nicht mehr jeder kommentieren/abstimmen kann. Die meisten erfolgreichen Opensource-Projekte fahren generell mit offenen Bugtrackern, weil eben diese durch die Offenheit leben. Beispiele dafür sind die Bugtracker von Firefox, Linux, Video Land Client, Chromium (die Basis von Google Chrome) und viele weitere. Offen einsehbare Bugs gehören zu einer guten Opensource-Entwicklung einfach dazu, denn sie bringen eine Menge an Vorteilen. So etwas ist also Standard.

Was nun Linden Lab getan hat, ist die Abstimmungskultur im JIRA schlagartig zu beenden. Gut, das ist deren Sache. Aber sie taten eben noch mehr, indem sie dafür sorgten, dass Bugs grundsätzlich nicht mehr öffenlich sind, auch die Bugs, die die Viewerentwicklung betreffen.

Und damit zeigen sie den externen Viewerentwicklern eindeutig den Stinkefinger, etwas anderes ist das nämlich nicht. Sie berauben diese Entwickler nämlich einer immens wichtigen Informationsquelle.

Wer das nicht glaubt, der sollte sich mal damit auseinandersetzen, was gerade in einem ähnlichen Fall passiert. Die Datenbank MySQL gehört schon seit längerem zu Oracle. Oracle selber entwickelt diese als Opensource auch weiter, aber es gibt mindestens zwei kommerzielle Konkurrenten zu MySQL, einmal Percona und dann MariaDB.

Was tut also Oracle, um seine eigene Datenbank zu pushen und die Entwicklung der Konkurrenz zu erschweren? Sie sorgen dafür, dass gewisse Bugs nicht mehr öffentlich sind und stellen zu gewissen Features im öffentlich zugänglichen Quellcode nicht mehr die Testfälle zur Verfügung.

Die externen Entwickler sehen dann in Release-Notes meinetwegen nur noch, Bug 123 und 456 wurde behoben – was aber der Bug gewesen ist, das wissen sie nicht mehr. Das erschwert ihnen also die Entwicklung und das Gleichziehen mit dem Mutterprodukt MySQL gehörig.

Ebenso wird es ihnen erschwert, die Kompatibilität ihrer eigenen Forks noch zu gewährleisten, wenn Oracle nicht mehr die dazu notwendigen Testfälle bereitstellt.

Aus Sicht von Oracle ist das ein logischer Schritt: man behindert die unleidliche Konkurrenz, hofft darauf, dass die Benutzer auch weiterhin den Arsch nicht hoch kriegen sondern bei MySQL bleiben und man so verstärkt Supportverträge verkaufen kann. Diesen Effekt, die unliebsame Konkurrenz so trotz Opensource abhängen zu wollen verstärkt Oracle noch dadurch, dass sie MySQL mit einer brachialen Geschwindigkeit weiter entwickeln.

Also alles in allem eine Sache, die in der MySQL-Nutzerschaft sehr skeptisch aufgenommen wird und kritisch beäugt, wie man beispielsweise bei Kris Köhntopp nachlesen kann.

So, und nun zurück zu Second Life und der JIRA-Reform: die Parallelen sind mehr als offensichtlich. Linden Lab lässt die Entwickler von alternativen Viewern am langen Arm verhungern, indem sie alle Bugreports nun als privat markieren, dazu kommt auch die sehr schnelle Weiterentwicklung der eigenen Viewerlinie.

Damit macht Linden Lab nichts anderes als Oracle mit seinen Konkurrenten: man zeigt ihnen den Stinkefinger und trocknet deren Tümpel aus. Gerade dieser Schritt von Seiten Linden Labs ist nun wirklich mal brachialer und auch folgenreicher als die damals stark kritisierte Havok-Unterlizenz, die ja nur optional ist.

Mit dieser Maßnahme schadet Linden Lab den Entwicklern von Firestorm&Co. nämlich wirklich massiv, und viele bemerken das nicht einmal.

Die Kathedrale und der Basar und wie Fragmentierung einem Projekt mehr schadet als nützt

Bartholomew Gallacher 9. September 2012 0 Kommentare

Eric S. Raymond verfasste und veröffentlichte 1996 einen der grundlegenden Essays zum Thema Opensource: „Die Kathedrale und der Basar.“ In diesem beleuchtet er genauer die unterschiedlichen Vorgehensweisen zwischen kommerzieller Softwareentwicklung und Opensource.

Herkömmliche Softwareentwicklung ist dabei für ihn die Kathedrale: es gibt einen Chefarchitekten, der genau bestimmt, in welche Richtung hin sich die Entwicklung bewegen wird, und dieser leitet das Projekt unangefochten.

Im Gegenzug meint er, dass Opensourcesoftware nach einem anderen Modell entwickelt wird, das er den Basar nennt: da jeder zu einem Projekt beitragen kann, gibt es wenn die Entwicklerbasis für ein Projekt groß genug ist, verschiedene alternative Ansätze zur Lösung desselben Problems, aus denen sich der Projektleiter das seiner Meinung nach am Besten geeignete rauspicken kann – oder man baut einfach beide gleichzeitig ein. Nach Raymonds Meinung ist der Basar wegen seiner Vielfalt der Kathedrale deutlich überlegen. Als erfolgreiche Bestätigung für dieses Modell sieht er den Linux-Kernel an.

Damit mag er Recht haben. Auch Opensimulator selber ist im Grunde so ein Basar: jeder, der zu diversen Problem beitragen will, der kann das natürlich gerne tun, und so ist es oft geschehen und geschieht es auch weiterhin. Auch ist zweifelsohne Opensimulator ein recht erfolgreiches Softwareprojekt: es gibt eine große Nutzerbasis, eine stabile Community um das Projekt und viele kennen es.

Dennoch hat Opensimulator in meinen Augen ein Problem, nämlich seine BSD-Lizenz. Das ist eine der zwei großen Opensource-Lizenzen, die es gibt.

Die bekanntere Lizenz ist von der amerikanischen Free Software Foundation die GPL. Die GPL selber wird auch gerne als virale Lizenz bezeichnet, denn sie besagt folgendes: hier hast du den Sourcecode, mach damit was du willst, solange du die Lizenz beachtest. Solltest du Änderungen an dem Projekt vornehmen und vertreiben, dann hast du auch diese Änderungen dem Projekt unentgeltlich zugänglich zu machen.

Oder anders gesagt: einmal Opensource, immer Opensource. Ein Beispiel dafür, was das genau bedeutet, ist das Android-Projekt. Die haben den Linuxkernel geforkt, jeder Smartphonehersteller nutzt dabei seine eigene Version inkl. Treibern und wegen der GPL sind sie dann dazu verpflichtet, diese Quellcodes der Allgemeinheit zugänglich zu machen. Das tun sie dann auch nach dem erscheinen einer Androidversion mehr oder weniger flott, und deshalb gibt es auch eine große Community an Custom ROMs und dergleichen mehr.

Die BSD-Lizenz selber ist liberaler, sie sagt nämlich nur folgendes: hier ist der Code, mach damit was du willst. Das einzige, was wir erwarten, ist dass du unseren Namen irgendwo nennst und fertig. Wenn du auf Basis dieses Codes kommerzielle Software entwickelst und verkaufen willst, dann kannst du das tun, den von dir auf unserem Projekt aufbauenden Quellcode aber musst du nicht veröffentlichen, wenn du nicht willst. Das ist genau der Gegensatz zur GPL, denn unter der GPL darf man das auch tun, aber muss eben den Quellcode mit den eigenen Änderungen veröffentlichen. Mehr Analysen zum Thema GPL und dessen Sinn liefert in gewohnt guter Qualität Kristian Köhntopp. Lesen!

Nun ist es so, dass Opensimulator die Basis vieler, kommerzieller Grids ist. Diesen kommerziellen Grids ist aber möglicherweise das Plain Vanilla Opensim nicht mächtig genug, weil ihnen da einfach gewisse Features fehlen oder sie ihnen nicht weit genug fortgeschritten sind. Das kommt ja vor, und warum auch nicht, das ist keine schlechte Sache, im Gegenteil es treibt zuerst einmal das Projekt voran und sorgt mitunter für die Entwicklung besserer Komponenten.

Das tut es nun auch tatsächlich, so manches kommerzielle Opensimgrid hat einen oder mehrere Entwickler, die beispielsweise eine bessere Scripting-Engine basteln, die Physik massiv aufbohren oder vieles andere mehr. Diese gridspezifischen Eigenheiten sind dann die Merkmale, mit denen die Grids unter anderem gegeneinander in Konkurrenz treten.

Nichts gegen Konkurrenz, und unter der BSD-Lizenz ist das auch alles erlaubt, aber das Ding ist dann dies: wegen der BSD-Lizenz besteht absolut kein Zwang, die Verbesserungen , Änderungen und Erweiterungen am Opensim-Code mit dem Projekt zu teilen. Was hier also faktisch passiert ist, dass es einen Haufen geschlossener Forks von Opensim gibt, die alle in house entwickelt und gepflegt werden, von denen aber je nach Politik des Entwicklers ggf. nur wieder sehr wenig zurück an die Community fließt.

Beispielsweise war das untergegangene Meta 7 Grid stolz auf seine eigens entwickelte Scripting Engine – und dann gingen sie pleite, die Engine verschwand mit ihnen. Wäre Opensim unter der GPL lizenziert, dann hätten sie diese veröffentlichen müssen und es ans Projekt zurückgeben müssen.

Nun sind Forks normalerweise kein Problem, solange gewährleistet ist, dass man noch innerhalb derselben Codebasis Quellcode tauschen kann. Das ist aber bei Opensim und seinen Abkömmlingen nicht überall unbedingt mehr gegeben.

Man stelle sich nur einmal vor, wie weit Opensim schon sein könnte, wenn es unter der GPL gestanden wäre und all diese netten Inhouse-Entwicklungen Bestandteil der Kerndistribution wären. Da es das aber leider nicht ist, ist das ein frommer Wunschtraum.

So aber bleibt es eben so, wie es ist: es gibt eine einigermaßen stabile Kerndistribution und viele, viele kommerzielle Grids mit ihren Eigenheiten. Sollte aber solch ein Grid untergehen, dann verschwindet mit dem auch dessen Inhalte und die auf deren Eigenheiten basierenden Dinge ziemlich sicher auf Nimmerwiedersehen. Das ist mit Meta 7 damals so geschehen, und keiner kann garantieren, dass nicht irgendwann noch andere Grids pleite gehen werden und dann das Spiel von vorne beginnt.

Schade, aber das ist eben so. Wer wirklich einigermaßen sicher in Sachen Opensimulator agieren will, der sollte daher besser nur die frei verfügbaren Komponenten einsetzen und sich nicht von irgendeiner Firma abhängig machen, die er kaum kennt, weil er gerade erst meinetwegen die Schnauze von Linden Lab voll hat.

Denn wieso sollte man sich von der einen, heftigen Umklammerung freiwillig direkt in die nächste begeben wollen? Wenn schon Freiheit, dann aber auch eben richtig!

Technische Grundlagen einfach erklärt, heute: was eigentlich genau ist Bittorrent?

Bartholomew Gallacher 29. August 2012 0 Kommentare

Bittorrent dürfte dem einen oder anderen ein Begriff sein, zumindest ab und an gehört hat man es sicher einmal, wenn man sich mit Computern beschäftigt. Angeblich ist es ja böse, vielleicht fallen einem dann dazu noch Sachen wie „The Pirate Bay“ in Schweden ein, die massiv auf Bittorrent setzen und zu den prägenden Gestalten der Szene gehören. Andere wiederum sagen, Bittorrent selber sei legal, es kommt nur darauf an, wie man damit umgeht. Was aber nun ist Bittorrent eigentlich genau?

Bittorrent selber ist zunächst einmal ein Netzwerkprotokoll, das vom Amerikaner Bram Cohen erfunden wurde. Cohen dachte sich damals, dass die zunehmende Verbreitung von Breitbandanschlüssen ans Internet doch auch dazu genutzt werden könnte, um das Downloaden von Dateien vom Server auf die einzelnen Rechner zuhause zu verlagern. Das würde Zeit und Kosten sparen, wenn jemand große Daten der Allgemeinheit zur Verfügung stellen wolle, wie Filme, Programme usw.

Das Problem an der Sache ist, dass ADSL asymmetrisch arbeitet. Während der Downstream, also die Geschwindigkeit vom Internet nach Hause im Megabitbereich liegt, ist umgekehrt der Upstream, also von zuhause ins Internet, meist um etliches langsamer. Dennoch wollte Cohen auf dieser Basis ein Verteilnetz für Dateien aufbauen, und das tat er auch.

Er löste das Problem folgendermaßen: zunächst einmal wird die gewünschte Datei über einen sog. Tracker zur Verfügung gestellt. Dieser verhackstückt die Datei in lauter kleine handliche Häppchen, auf Englisch einfach Chunk genannt, die üblicherweise 512 KB groß sind. Wenn man sich entschließt, einen Torrent herunterladen zu wollen, dann braucht man dafür zunächst einmal einen passenden Client. Diese gibt es kostenlos und wie Sand am Meer für alle Betriebssysteme.

Dabei kommt es dann zu einer Schwarmbildung: der Client meldet sich am gewünschten Tracker an, lädt die ersten Happen der Datei herunter (das kann entweder vom Tracker direkt kommen oder aber vom ersten Client) und kann recht schnell immer dank der netten Größe feststellen, welche Happen er schon hat und welche noch fehlen. Diesen Vorgang bezeichnet man auch einfach als Leeching. Nun kommen aber, wenn der Torrent beliebt genug ist, weitere Clients dazu, die dieselbe Datei wollen und da wird es nun interessant: der Tracker weiß nämlich genau, welche Happen welcher verfügbare Client bereits heruntergeladen hat und sagt das dem anfordernden Client. Klingt komplizierter, als es ist, es bedeutet einfach, dass der anfordernde Client sich den Chunk vom anderen Client holt und nicht mehr vom Server.

Und, so die Theorie als auch Praxis, irgendwann wenn genügend Chunks in dem Schwarm verteilt worden sind und die Clients lange genug online sind, muss der Tracker selber nichts mehr ausliefern, sondern bedient alle Anfragen direkt aus dem Schwarm. Das ist das gewollte Endziel, und genau das spart dem Autor der Datei eben eine Menge Geld, denn nun erledigt der Schwarm für ihn die Arbeit.

Da idealerweise genügend Clients im Schwarm vorhanden sind, die genau das tun – man spricht dabei dann von Seeding – funktioniert das in der Praxis oft genug und vor allem auch schnell genug. Weil bei Bittorrent Client zu Client im Schwarm spricht, nennt man es auch ein Peer-to-Peer-Protokoll (P2P).

Welche Dateien man dabei zur Verfügung stellt, ist Bittorrent recht herzlich egal. Es ist ein Programm und ein Protokoll, es prüft das nicht, ebenso wenig wie ein Emailprogramm prüft, welche Anhänge man da nun genau verschickt. Man kann es zum Verteilen von großen Programmen verwenden, Filmen, kleinen Dateien und und und…

Eine gern genutzte Möglichkeit ist beispielsweise bei den Machern von Linuxdistributionen das Verteilen derer ISO-Images, bei Chip.de ist auch ein Tracker in Betrieb und die Patchverteilung von Blizzard bei WoW basiert auch auf Bittorrent: der Client ist im Launcher direkt eingebaut und werkelt im Automodus vor sich hin. Ein bekannter Standalone-Client für Windows ist übrigens uTorrent.

Es kommt also bei Bittorrent einfach darauf an, was man daraus macht. Der Einsatz selber ist legal, es ist allerdings so, dass manche Internetprovider gerne den Traffic für Bittorrent herunterdrosseln. Aber auch dagegen fanden die Macher eine Lösung, indem sie einfach in den besseren Clients den Traffic komplett verschlüsseln, so dass eine Analyse der Pakete fehlschlägt.

Ein „Schwachpunkt“ im Protokoll war lange Zeit, dass es eben Tracker benötigt. Wurde der Tracker abgeschaltet, dann stand auch der Inhalt nicht mehr zur Verfügung. Inzwischen aber ist man auch da weiter, indem die besseren Clients heutzutage eine verteilte Hashtabelle beherrschen können (DHT), so dass ein komplett trackerloser Betrieb möglich ist.

So oder so, Bittorrent hat sich schon seit langem als günstige Möglichkeit, sehr große Datenmengen über einen Schwarm günstig zu verteilen, etabliert. Es wird so schnell nicht mehr verschwinden und es kommt einfach darauf an, was man daraus eben macht. Wer natürlich geschützte Filme darüber bereit stellen sollte, der braucht sich dann aber auch nicht wundern, wenn das Folgen hat.

Die Programmiersprache Lua

Bartholomew Gallacher 19. August 2012 0 Kommentare

Viele Spiele kommen ja heutzutage nicht mehr ohne eine irgendwie geartete Programmiersprache aus, in denen gewisse Sachen geskriptet sind und die ggf. zur Entwicklung von Erweiterungen zur Verfügung gestellt wird.

Ein bekannter Vertreter war früher beispielsweise S.C.U.M.M. von Lucas Arts, in dem viele von deren berühmten Adventures (wie Monkey Island, Day of the Tentacle und weitere) programmiert worden sind. Heutzutage aber ist der bekannteste Vertreter dieser Art eindeutig Lua.

Wo kommt es her?
Lua ist ursprünglich eine Entwicklung einer katholischen Universität aus Rio de Janeiro in Brasilien. Die Entwickler beschreiben Lua als schnelle, leichtgewichtige, mächtige und einbettbare Skriptsprache. Es ist sehr einfach möglich, Lua in beliebige Spiele als Skriptsprache einzubetten und dann zu benutzen. Der gepackte Download hat gerade einmal 182 Kilobyte und Lua selber ist in nur 20.000 Zeilen C-Code implementiert. Damit ist die Codebasis klein und überschaubar, also auch sehr gut wartungsfähig.

Was bedeutet der Name? Ist das eine Abkürzung?
Nein, Lua ist einfach nur portugiesisch für Mond. Das ist alles.

Was kostet das?
Nichts. Lua wird unter der wohlbekannten MIT-Lizenz zur Verfügung gestellt, die grob gesagt „Mach damit, was dir beliebt, Hauptsache du nennst irgendwo unseren Namen“ als Bedingung hat. Daher ist Lua sehr weit verbreitet.

Wo gibt es Dokumentationen zu Lua?
Zu allererst in Englisch auf der Seite des Projekts, daneben aber auch auf Deutsch wie beispielsweise hier ein Einsteigerkurs und noch eine Referenz.

Welche Spiele nutzen denn nun Lua?
Die Liste ist lang, bekannte Spiele sind unter anderem Die Siedler: das Erbe der Könige, Monkey Island ab Version drei, World of Warcraft, Angry Birds, Baldur’s Gate, Civilization V, Sim City 4, Mafia II und viele andere.

Warum sollte man sich mit Lua beschäftigen?
Ganz einfach: wer schon immer mal wissen wollte, wie eine Spielmechanik geskriptet worden ist oder für Spiele wie World of Warcraft, bei denen die Erweiterungen komplett in Lua geschrieben sind, vielleicht selbst Add-Ons schreiben will oder diese zumindest verstehen, der kommt um Kenntnisse in Lua nicht herum.

Ist Lua neben Spielen noch weiter verbreitet?
Kaum.  Es gibt Ausnahmen wie beispielsweise Prosody, ein komplett in Lua geschriebener Jabberserver, aber die Liste dieser Programme ist dann doch sehr überschaubar.