Das deutsche Python-Forum

Zwei Anmerkungen von mir:

Das Patent-Argument ist keines. Patente drohen immer und überall und sind sprachunabhängig. Wenn du das selbe in Python schreibst, was in der C#-Bibliothek steht und patentiert ist, dann hast du das Patent auch verletzt. Und wenn du dich entschließt, die ganze Patentscheiße zu ignorieren, dann kannst du das auch in C# machen. Tatsächlich ist dort die Situation noch etwas besser, denn Microsoft hat öffentlich erklärt, dass sie Lizenzen für ihre Patente gewähren und hoffentlich so viele Patente halten, dass niemand wagt, sie anzugreifen. Außer natürlich Patenttrolle, die nichts haben, was sie verlieren könnten. Aber diese werden sich an Microsoft wenden, denn da ist mehr zu holen, als bei einem Entwickler. So hat Sun vor einigen Jahren ja mal die Java-Community vor einem (IMHO lächerlichen) RPC-Patent für die gar nicht lächerliche Summe von $90 Mio freigekauft. Wetten, dass das Patent auf auch Python-Programme zutrifft, die RPC machen?

Wo ich gerade XML-RPC las: http://www.patentstorm.us/patents/7028312.html - bis 2019 also bitte kein XML-RPC oder Merrick, Allen oder Lapp könnten rechtliche Schritte einreichen. Patentdrohungen sind überall!

Wenn man den SecondLife-Client benutzen will (ist das eigentlich gestattet, diesen für andere Server zu benutzen, theoretisch könnten die das ja untersagt haben - oder er ist patentiert ;), muss der eigene Server ja das selbe Protokoll wie der andere offene Server da (und die SecondLife-Server selbst) sprechen. Im wesentlichen würde man also eine Implementierungssprache durch eine andere austauschen. Ich sehe da noch keinen großen Vorteil. Zudem, wenn du eine weniger großzügige Lizenz einsetzen willst, als die aktuelle "mach was du willst" BSD-Lizenz.

Ich meine mal aufgeschnappt zu haben, dass Lindenlabs selbst Mono einsetzt und extra um Continuations erweitert hat, damit Prozesse angehalten und von einem Server auf einen anderen transportiert werden können und dort weiterlaufen können. So könnte es bei OpenSim dank Mono doch durchaus Vorteile im Codeaustausch mit Lindenlabs geben, sollten die noch mehr Server-Code freigeben. Zudem verstehe ich das so, dass man doch in SecondLife überall so kleine Programme schreibt, die dann auf dem Server laufen. Diese in einer beliebigen .NET-Sprache zu verfassen statt auf diese selbst gemachte Scriptsprache von Lindenlabs (die der Autor im selben Vortrag, in dem sie die etwas über Mono erzählt haben als nicht wirklich gelungen bezeichnet hat) angewiesen zu sein und dafür (in Python) einen eigenen Interpreter schreiben zu müssen.

Der Artikel auf Wikipedia freut sich zwar, dass OpenSim der Defacto-Standard werden könnte, doch ich vermute doch, dass er die selbe Architektur wie SecondLife hat und diese war AFAIK entscheidend dafür verantwortlich, dass das ganze Ding nicht skaliert.

Gibt es eigentlich mehr Informationen darüber, wie Eve Online serverseitig funktioniert? Die haben es doch wohl als eine der ganz wenigen geschafft, mehr als ein paar hundert (im Falls von SecondLife) oder paar Tausend (im Falle der meisten MMORPGs wie WoW) User auf einem Server(-Grid) zu versammeln. Oder sind Raumschiffe im Weltall einfacher zu verwalten (weil man ja quasi nur einen Vektor im Raum (6 Zahlen) braucht) als eine Welt am Boden?

Ich bin kein Experte auf dem Gebiet, aber obwohl ich Python mag, würde ich's nicht für so ein Projekt einsetzen. Meine Annahme wäre, dass man nebenläufige Prozesse in großer Zahl braucht. Da fällt mir natürlich sofort Erlang ein. Allerdings ist mir diese Programmiersprache zu archaisch, sodass ich vielleicht über Clojure nachdenken würde (Lisp-Syntax mag ich im Gegensatz zu Prolog-Syntax nämlich). Allerdings erfordert das (wie übrigens auch Twisted) eine reactive Programmierung und das Actor-Modell von Erlang ist IMHO einfacher zu benutzen. Wenn es ein Forschungsprojekt wäre und ich genügend Zeit hätte, würde ich vielleicht darüber nachdenken, die Semantik von Clojure oder Erlang und die Syntax von Python zu verschmelzen. Man müsste Python möglichst die Dictionaries austreiben, um es schnell zu bekommen. Oder man nimmt gleich JavaScript.

Es gibt übrigens auch von Sun so ein Virtuelle-Welten-Projekt. Darkstar und Deamland sind zwei Stichworte. Mehr weiß ich darüber auch nicht, musste aber bei Clojure als auf der JVM laufenden Sprache daran denken, dass man hier vielleicht Gigantenschultern hat, auf die man aufsteigen kann.

Stefan

Hallo,
Zu MONO und Patente gibt es sehr viele Threads in Netz, ich denke, so eine Diskussion sprengt den Rahmen hier.

sma hat geschrieben: Wenn man den SecondLife-Client benutzen will (ist das eigentlich gestattet, diesen für andere Server zu benutzen, theoretisch könnten die das ja untersagt haben - oder er ist patentiert , muss der eigene Server ja das selbe Protokoll wie der andere offene Server da (und die SecondLife-Server selbst) sprechen. Im wesentlichen würde man also eine Implementierungssprache durch eine andere austauschen. Ich sehe da noch keinen großen Vorteil. Zudem, wenn du eine weniger großzügige Lizenz einsetzen willst, als die aktuelle "mach was du willst" BSD-Lizenz.

Der Secondlife Client steht unter der GPL, es gibt auch andere Clients. Und ich halte die GPL(Linux) für interessanter als die BSD Lizenz.
Also, Ich habe seit 1 1/2 Jahren ein Grid laufen, auf 3 Servern in Netz( 2 root-Server 4GB, dual-core) und eine VM. Und es gab und gibt erhebliche Probleme mit MONO, die Linux-Version von MONO hinkt gewaltig hinter der .Net hinterher, Pakete für Debian, Ubuntu,... sind teilweise nur im Experimentellen Zweig zu erhalten, crashs oder 100% CPU Last sind häufig ! Seit 3 Monaten bekomme ich neue Versionen gar nicht mehr zum Laufen, die Lösung wäre alles löschen und neu installieren. Also habe ich diesen Vorschlag in den Raum gestellt.

Ich meine mal aufgeschnappt zu haben, dass Lindenlabs selbst Mono einsetzt und extra um Continuations erweitert hat, damit Prozesse angehalten und von einem Server auf einen anderen transportiert werden können und dort weiterlaufen können. So könnte es bei OpenSim dank Mono doch durchaus Vorteile im Codeaustausch mit Lindenlabs geben, sollten die noch mehr Server-Code freigeben.

Die Server von LindenLabs sind in C++ programmiert, MONO wird neben den LSL als Scriptsprache inWorld eingesetzt.
Ich stelle mir es so vor, das erstmal die Datenserver durch Python Module ersetzt werden, danach dann der Sim-Server. Ja, ich weiss, dass es erhebliche Probleme gibt, aber ich würde es gerne probieren.

Tschüss
Jürgen

Zu MONO und Patente gibt es sehr viele Threads in Netz, ich denke, so eine Diskussion sprengt den Rahmen hier.

Da hast du sicherlich recht. Mich stört nur, dass 90% der ganzen Diskussion FUD ist. Nicht das ich Microsoft verteidigen möchte, aber so schlecht wie sein Ruf ist Mono nun auch nicht.

Bei der Lizenzfrage gab ich nur zu bedenken, dass aufgrund der Einschränkungen der GPL das andere Projekt als interessanter angesehen werden könnte. Welche Lizenz der Client hat, ist ja egal.

Wenn Mono in der Entwicklung und Stabilität Microsofts Implementierung nicht hinterherhinkt, laufen dann die meisten dieser Systeme unter Windows? Wird das vielleicht auch unter Windows implementiert? Wenn es dir um den Betrieb einer virtuellen Welt geht, warum wählst du dann nicht selbst ebenfalls Windows als Server?

Ich verstehe jetzt aber den Vorschlag, warum es Sinn machen könnte, das existierende System in einer Sprache, die Linux-näher ist, nochmals neu zu entwickeln. Aber wäre es nicht sinnvoller, darauf zu warten bzw. mitzuhelfen, dass Mono besser wird? Ich verfolge nur die Ankündigungen in Miguel de Icazas Blog, doch da freuen sie sich immer, wie toll und noch besser Mono geworden ist.

Andererseits ist sinnvoll nicht gleichbedeutend mit dem, was auch Spass macht :) Wenn schon neu schreiben, dann würde ich's wohl in Java versuchen, wissend, dass man dadurch die beste (schnellste) plattformunabhängige Implementierung bekäme. Zudem könnte man wahrscheinlich den Quelltext halbautomatisch umwandeln - vielleicht sogar mit einem Python-Programm ;)

Ich weiß nicht, was Daten-Server und Sim-Server sind - offenbar zwei getrennte Systeme - doch wenn sie klein genug sind und hauptsächlich "IO bound", dann sollte das auch in Python gehen. Und ein spannendes Projekt ist das bestimmt. Außerdem lernt man wohl zwangsläufig jede Menge C#

Stefan

sma hat geschrieben:Wenn Mono in der Entwicklung und Stabilität Microsofts Implementierung nicht hinterherhinkt, laufen dann die meisten dieser Systeme unter Windows? Wird das vielleicht auch unter Windows implementiert? Wenn es dir um den Betrieb einer virtuellen Welt geht, warum wählst du dann nicht selbst ebenfalls Windows als Server?
Stefan

Hallo,
Es hinkt aber beachtlich hinterher, hier nur kurz aus der wikipedia:

Mit der am 6. Oktober 2008 veröffentlichten Version 2.0 wurden die wichtigsten Eigenschaften von .NET 2.0 in Mono hinzugefügt und es gibt mit dem Projekt Olive auch eine Initiative, die neueren Technologien von .NET 3.0 und .NET 3.5 zu implementieren

Also erst geplant, und noch weit entfernt, so das es meiner Ansicht nach noch 2-4 Jahre hinterherhinkt.

Auch aus der Wikipedia:

Die grundlegenden Technologien sind teilweise durch Microsoft bei Ecma International und der ISO standardisiert worden. Microsoft garantiert eine Lizenzierung der ECMA-Teile auf RAND-Basis. Andere Teile, wie zum Beispiel Windows Forms, ADO.NET, und ASP.NET sind hiervon jedoch ausgeschlossen.

Also müßte ich Windows benutzen. Damit hätte ich praktisch gesehen nicht mehr die freie Wahl des Betriebssystems und müßte auch noch Lizenzgebühren bezahlen. Dies wäre für mich bei einem bedeutenden Projekt nicht tragbar, deshalb will ich ja eine freie Alternative haben, die dann, so meine Hoffnung, wesentlich stabiler läuft.

Mein persönlicher Eindruck ist eben, das MONO sehr schwer zu händeln ist, unheimlich Resourcen hungrig ist und sehr instabil.
Da würde ich eine schnelle, leichte, stabile Python-Variante vorziehen.

Es hängt natürlich hauptsächlich davon ab, ob überhaupt ein paar Entwickler die Zeit für eine Initative investieren wollen. Das Python für größere Projekte geeignet ist, steht für mich außer Frage.

Tschüss
Jürgen

Eine Neuentwicklung kostet aber auch erheblich Zeit und wird gerade in der Anfangsphase dem Vorbild in punkto Stabilität hinterherhinken. Bzw. im Funktionsumfang. Ob es da nicht schneller ist, auf eine stabilere Umgebung zu warten oder gar daran mitzuwirken?

Pekh hat geschrieben:Eine Neuentwicklung kostet aber auch erheblich Zeit und wird gerade in der Anfangsphase dem Vorbild in punkto Stabilität hinterherhinken. Bzw. im Funktionsumfang. Ob es da nicht schneller ist, auf eine stabilere Umgebung zu warten oder gar daran mitzuwirken?

Hallo,
Da gibt es natürlich eine Menge Beispiele bei denen so etwas erfolgreich war und genauso viele, wo es nicht geklappt hat.
Und viele Beispiele einer erfolgreichen Koexistenz. Es kommt nur darauf an, was wir daraus machen.

Tschüss
Jürgen

Habe gerade einen Blick in den C#-Quelltext von der opensimulator-Webseite geworfen, der mit 20 MB Größe offenbar auch die übersetzten Programme enthält. Ich rate, dass "OpenSim" das Verzeichnis ist, wo man den Quelltext findet. Der besteht aus über 1100 C#-Dateien mit über 360.000 LoC. Selbst unter der Annahme, dass in jeder Datei 30 Zeilen Copyright zu finden sind, sind das mindestens 300.000 LoC und eine gewaltige Aufgabe, das in Python umzuschreiben. Ich würde darauf tippen, dass man etwa 1/3 (weil der Quelltext einer Stichprobe zufolge wohl { } alleine in einer Zeile hat) in Python braucht. Selbst wenn man 50 LoC pro Stunde schafft, sind das 2000 Stunden Arbeit - oder etwa 1 1/2 Personenjahre. Nur um den jetzigen Zustand zu haben, der sich in dieser Zeit natürlich weiter entwickeln wird.

Bei diesem Aufwand würde ich - wenn überhaupt - versuchen, den Quelltext so weit es geht, automatisch von C# nach Python zu portieren. Selbst, wenn das Ergebnis dann stilistisch schlechter Python-Code ist. Von da kann man aber glaube ich schneller weitermachen, als wenn man's manuell portiert.

Hier ist ein Beispiel: http://paste.pocoo.org/show/160580/ - Das war natürlich per Hand. Ich habe mir nicht die Mühe gemacht, die 14 "using" in imports zu übersetzen, aber das müsste man. Statt Code, der z.B. Convert oder Hashtable benutzt umzuschreiben, würde ich lieber passende Klassen in Python bauen. Auch wenn man's in Python vielleicht auch so schreiben könnte: http://paste.pocoo.org/show/160585/

Stefan

oder man macht etwas komplett neues ohen etwas zu protieren..

sma hat geschrieben:Selbst wenn man 50 LoC pro Stunde schafft, sind das 2000 Stunden Arbeit - oder etwa 1 1/2 Personenjahre.

Ich habe mir zwischen Weihnachten und Neujahr das ganze mal angesehen. Es sieht nicht ganz so schlimm aus als ich dachte.
Ich habe mir erstmal die Datenserver angeschaut, das sind der Gridserver, userserver, Inventoryserver und der Assetserver. Diese laufen bei mir auf einen Rechner, die sims laufen auf 2 anderen Rechnern. Da der c# Quelltext wirklich umfangreich ist, habe ich mir lieber mit ngrep den netzwerkverkehr angesehen.
Dort sieht alles relativ einfach aus, also habe ich das Projekt gestartet und ein wenig programmiert.

Der umfangreichste Teil war einfach ein tool zu schreiben, das eine Postgres-Datenbank abcheckt und ggf. Tabellen und spalten anlegt oder modifiziert.

Dav1d hat geschrieben:oder man macht etwas komplett neues ohne etwas zu portieren..

Genau das ist es, was gemacht werden sollte ! Denn opensim ist ein fantastisches Projekt, aber zusehr darauf bedacht, alles möglich zu machen und möglichst elegant zu programmieren.
Als ein Beispiel, der userlogin:
der Viewer sendet eine xmlrpc anfrage, c# startet eine wirklich umfangreiche aktion, mehrere 100 Zeilen Code, ich schätze sogar über 1000 Zeilen. Dann werden die Ergebnisse zu anderen Types convertiert und zurückgesendet. Sehr elegant, sehr aufwendig.
Ich habe es in Python so gelöst:

Code: Alles auswählen

dicResult = self.getLoginData(args['first'],  args['last'], args['passwd'],  args['start'])
return dicResult

Code: Alles auswählen

def getLoginData(self, sUsername, sLastname, sPassword, sStartPosition):
        sSql = "select users.uuid as uuid, users.lastname as last_nam....
result = self.db_com.xmlrpc_executeNormalQuery(sSql)
return result[0]

Im Prinzip sehe ich es so: Es werden hauptsächlich Daten aus einer SQL-Datenbank gelesen und gepseichert, ansonsten nur noch einige Überprüfungen. Das opensim-projekt kann nur eine Untermenge an SQL Befehlen nutzen, da sie sqllite, mysql, oracle, mssql, ... usw. unterstützen. Damit wird alles sehr umfangreich und kompliziert. Wir würden hier mit ca. 10% an Code klarkommen, denn wir könnten alles auf Postgres anpassen, trigger, functions und Proceduren nutzen.

Ich habe ein wenig weiter programmiert, und die sims melden sich bei dem Python-Server erfolgreich an und der userlogin geht jetzt bis Stage 8 ( von Stage 10).

Also, ich habe das Projekt bei Berlios angemeldet und dort meine Sachen ins SVN gestellt:

http://developer.berlios.de/projects/py3dworlds/

Wie gesagt, ich finde das Projekt durchführbar und das sogar in einer akzeptablen Zeit. Vielleicht haben ja doch ein paar von euch Zeit und Lust mitzumachen.

Tschüss
Jürgen

Ich hätte Lust, habe mich aber noch nie mit Datenbanken beschäftigt (naja ein bisschen MySQL mit PHP)

Gibts irgend eine Anlaufstelle wo man mit dir schreiben kann (IRC, ICQ..)

Dav1d hat geschrieben:Ich hätte Lust, habe mich aber noch nie mit Datenbanken beschäftigt (naja ein bisschen MySQL mit PHP)

Gibts irgend eine Anlaufstelle wo man mit dir schreiben kann (IRC, ICQ..)

Das ist toll

mehrere Möglichkeiten:
jabber(XMPP) jhamel@cuonsim2.de
email: jhamel (at) cyrus-computer.de

oder anmelden bei berlios.de, dann kann ich dich dem Projekt hinzufügen.

Das mit der Datenbank ist nicht so ein Problem, es ist einfaches SQL bzw. ich kenne mich da einigermaßen aus.
Schwieriger ist es wohl, an die Informationen heranzukommen, ich habe 80% meiner Zeit dafür verwendet. Ich habe ins SVN auch 2 Protokolle gestellt, die den Datenverkehr aufzeigen swischen den Clients und den Servern. Ich war am Anfang etwas confus was die Werte für die Rückgabe anging, das ist wirklich ätzend !!!! So wird ein Integer Datenwert aus der Datenbank mal als int, dann als int4(bigint) oder als string zurückgesendet. Das ist natürlich nur unnötig kompliziert und sollte von uns später bereinigt werden. Ein Beispiel sieht zur Zeit so aus:
Datenbank Integer --> umwandeln String --> senden , dann im Empfänger String --> umwandeln in Integer. Nicht gerade schön !

Aber nicht wirklich schwierig, nur ätzend ))))

ok, ich freue mich auf deine Nachricht.

Tschüss
Jürgen

Hallo,
aus dieser Idee ist nun ein richtiges Projekt geworden, gehostet auf http://sourceforge.net/projects/py3d-worlds/. Wir sind allerdings wirklich zu wenig Entwicker ( nur 3 Stück) haben aber schon eine Menge geschafft. Heute ist es auch zum erstenmal gelungen, das ein neuer User einen Account erstellen kann und sich bei der Sim einloggen kann. Wie geplant sind wir so vorgegangen, das wir erstmal die 4 Grid-Server auf Python umschreiben, und wir haben zusätzlich einen Webserver geschrieben, der neue Accounts in der Datenbank anlegt.
Vielleicht haben ja doch noch 1 oder 2 von euch Lust, mitzumachen, ich würde mich freuen.

Tschüss
Jürgen Hamel

Schön zu hören. Wäre nett wenn du uns hier auf den laufenden halten könntest...

Das deutsche Python-Forum

3d Simulator Welt