secondlife

Publié le 14 Juin 2008

Le bruit courai par ci par la qu'une bande de rigolos ont utilisé massivement des copybot pour copier des milliers d'objets des plus grand créateurs de SL.

Il y a quelques heures, Linden à fermé leurs sims et supprimés leur comptes sans menagement, après qu'une plainte ai été deposée. Certains d'entre eux sont francais. Je suis curieux de voir comment ca va finir.

*pan* dans leur gueule ! hin hin hin ! GG Linden Lab ;)

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 10 Juin 2008

Un des gros problème de la francogrid à été pendant longtemps son système d'inscription.
Le problème est maintenant reglé et l'inscription devrait se passer sans encombre.


Cela se passe ici : http://user.francogrid.com/index.php?page=create

Si vous rencontrez des problèmes d'inscription merci de le signaler en commentaire sur ce blog, avec le detail des problèmes et/ou diffcultés rencontrées.

Un autre système est en cours de réalisation, encore plus simple... et bien mieux adapté.

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 10 Juin 2008

Je commence a m'apercevoir que je communiquai très peu, voire pas du tout, en dehors de Second Life. C'est certe un bon mode de communication, mais etant donné ma situation dans SL c'etait un peu ... limité. "Bonjour, ca va, merci. J'suis occupé, a+"


Maintenant que je suis à la "retraite", j'ai beaucoup plus de temps a consacrer à autre chose. SL ne me manque pas le moins du monde et je n'ai pas l'impression de "surcompenser" en me rabatant sur le blog. Avant je n'avais pas le temps, maintenant je l'ai. C'est aussi simple que ca.

Un autre soucis, venant encore de ma situation dans SL, était l'influence de mes écrits sur Second Life. Qui me limitai parfois dans ce que j'avais envie d'écrire. Un peu comme les blogs de CEO, mais a une bien moindre echelle bien sur ;)

Donc je vais poster plus souvent, c'est déjà le cas d'ailleur, et j'ai bien envie d'en faire ma Resolution N°2.

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 8 Juin 2008

Je reviens un petit peu sur 010 Editor et le format de texture.entries.

Ou je vais compliquer les choses... pour les rendres plus simple d'utilisation ;)
(L'informaticien est en grand faineant, mais il est capable de deployer une grande quantité d'energie afin de faire faire a l'ordinateur le maximum de boulot possible, et le minimum pour lui).


On va faire en sorte que la structure de textures.entries soit un peu plus lisible, voir utilisable a d'autres fins.
En particulier a propos de l'UUID.
Une UUID comme on la connait est sous cette forme : "a822ff2b-ff02-461d-b45d-dcd10a2de0c2"

C'est un ensemble d'octets au format en hexadecimal, separé par des "-" a certains endroits (pour des raisons qui m'echappent).

Hors, avec l'exemple de la partie 1, 010 Editor affiche une serie de chiffres decimaux qui n'ont aucun interets.
LLUUID stocke l'UUID, est le resultat presenté ne ressemble en rien a une UUID, mais a un tableau de 16 elements au format decimal.
Logique, c'est ce qu'on lui a demandé de faire.

Pour rappel, on a defini LLUID de cette facon : typedef ubyte LLUUID[16];
Et... c'est tres bien comme ca. il n'existe pas de type "chaine de caracteres en hexadecimal  separé par des tirets de temps en temps". C'est juste une histoire de format de presentation, pas de format de données.


Il est possible de dire a 010 Editor : "A chaque fois que tu va lire cette donnée, tu vas faire le travail que je vais te demander et qui est decrit dans une fonction que je vais te decrire".

Dans la partie 1 on a declaré et utilisé directement les structures. pour des raisons de simplicité.
Cette fois, de la meme maniere qu'on a créé le type "LLUID" (tableau de 16 ubyte) on va creer un type de structure, auquel on va rajouter un mot clé pour dire a 010 ce qu'il faudra faire a chaque fois qu'il lira ce type.

typedef ubyte LLUUID[16];

typedef struct
{
    float mVersion;
    uint32 mEntries;
} EntriesHeader;

typedef struct
{
    LLUUID mID;
    int32 mSize;
    time_t mTime;
} EntriesBody <read=ReadEntriesBody>;


A chaque lecture de EntriesBody, 010 Editor va executer la fonction "ReadEntriesBody".
Que l'on declare ici :

string ReadEntriesBody( EntriesBody &body)
{
    string s;
 SPrintf(s,"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",body.mID[0],body.mID[1],body.mID[2],body.mID[3],body.mID[4],body.mID[5],body.mID[6],body.mID[7],body.mID[8],body.mID[9],body.mID[10],body.mID[11],body.mID[12],body.mID[13],body.mID[14],body.mID[15]);
    return s;
}


La fonction Sprintf permet d'afficher un texte dans un format specifié.
Pour resumer :
"%02x" veut dire "affiche la donnée te correpondant (body.mID[0] pour la premier %02x, et ainsi de suite) au format hexadimal, sur 2 caracteres".
La syntaxe des regles de formatage pour Sprintf est un standard decrit partout sur le web (c'est la meme regle que le bon vieux "printf" du langage C (ou autre langages)).

On a declaré nos nouveaux, type, reste a les utiliser, on rajoute a la fin :
EntriesHeader header;
EntriesBody body[header.mEntries];   

Et voila. On se retrouve avec 010 Editor qui nous affiche les UUID au format qu'on connais. (et qui se trouve etre aussi le format du nom de fichier que l'ont peut trouver dans les reperoites de texture du cache secondlife).

cafééééééééééééééé !

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 8 Juin 2008

Pour ceux qui n'ont pas eu la patience de lire la partie 1 jusqu'au bout :
- Linden Lab a fait un sac de noeud pour rendre difficile le "vol de texture" via le cache. (securité par l'obscurité)
- Ce sac de noeud impacte très peu sur les performances, totalement negligeable.
- Un maximum de temps est perdue dans la decompression jpeg2000 et c'est deja optimisé a mort.

A quoi sert le cache ?
Le cache permet de stocker des textures sur le disque dur, plutot que de les retelecharger a chaque fois.
Un gain de temps, de bande passante, et de ressource CPU pour les serveurs SecondLife.

Pourquoi faut il le vider regulierement ?
Il ne faut pas le faire regulierement !

Pourquoi faut il le vider, parfois ?
Parce qu'il peut etre corrompu pour diverses raisons.


Qui sont ?
- un plantage pur et simple de l'application pile au moment ou elle etait en train d'editer le cache. Ce qui rend le fichier "inconcistant". A savoir : ce qu'il y a ecris dans le fichier A ne correpond pas a ce qu'on est sencé trouver dans le fichier B. Ou alors l'application n'a pas eu le temps d'ecrire la totalité du fichier entete par exemple, et au redemarrage l'application est toute embrouillée parce ce qu'il lui manque des informations pour utiliser le cache. 2 raisons parmis d'autres.

- Beaucoup plus frequent : l'application a "freezé" au moment ou elle etait en train de reorganiser le cache. Elle freeze justement parce qu'elle est en train de le reorganiser et qu'elle a besoin de stopper certaines operation pendant cette reorganisation. (typiquement : Empecher l'acces au cache pendant cette reorganisation).


Pourquoi reorganiser le cache :
C'est lié a sa taille. (il n'y a pas que la taille qui compte, mais ca aide ;) ).

Nous n'avons pas un espace disque illimité. Et afin que SecondLife ne remplisse pas l'integralité du disque dur
 nous pouvons indiquer une taille maximale que nous voulons consacrer au cache.
Plus le cache est gros, plus l'operation "est ce que cette texture dont j'ai besoin est stockée sur mon disque ? ou dois-je la telecharger ?" prend du temps.

A chaque fois que SecondLife telecharge une texture, il la transforme en sac de noeud (voir partie 1) et la met en cache.
A ce moment la il en profite pour verifier la taille du cache. Si la taille excede la taille maximale qui lui est autorisé, il va faire un nettoyage de printemps en virant 10% des textures stockée.

Ce qui  mene a un "leger freeze" de l'application. Car pendant le nettoyage, toutes les operations necessitant un acces au cache sont bloquées. Et comme secondlife est multithread ca n'arrange pas les choses (beaucoup plus difficile a coder, plus de bugs et de "bloquages" possible.

Bien sur, plus le cache est gros, plus le nettoyage est lent.
Je ne detaillerai pas le precessus du nettoyage car je ne suis pas absoluement certain de la methode employée. (visiblement les textures les plus anciennes sont supprimée du cache, d'ou le fait que la "date de stockage" fasse partie de l'index des textures (voir le post sur la structure de texture.entries)

Malheureusement, ce "freeze" qui peut etre plus ou moins long peut etre assimilé a un plantage de l'appli et elle est fermée violament par l'utilisateur. La reorganisation est laissée en plan, le cache est inutilisable ou, pire, mal utilisé (ce qui fait remplenter l'application et qu'on soit obligé de vider le cache).


D'ou l'interet de ne pas mettre un cache trop gros quand l'ordinateur est un peu faiblard.
A cela on pourrait rajouter que le FileSystem  de Windows est une grosse merde qui rend les operations encore plus lentes. Il y a enormement de reécritures et les fichiers finissent horriblement fragmentés. (et c'est vraiment specifique a windows).
De plus windows n'apprecie pas trop quand il y a trop de fichier dans un meme repertoire. C'est pour cela que les fichiers de textures sont dispersée dans des sous-repertoire.

Il y aurai des solutions un peu plus optimales pour cacher ces textures rapidement, mais l'optimisation ne serait efficace qu'avec un OS utilisant un filesystem digne de ce nom (linux, macOS X, ...) alors que cela empirerai les choses sous Windows.


Il y a vraiment beaucoup de discussions sur SLDev a propos du cache, car c'est vraiment un point qui impacte fortement les performances. Etant donné que c'est la decompression du format jpeg2000 (les textures sont stockée dans ce format) qui prend le plus de temps, l'idée évoquée est d'utiliser un autre format, plus rapide. (les plus rapides etant les format sans compression tels que le TGA).

Vous pouvez trouver un bref resumé des discussions et propositions ici : http://wiki.secondlife.com/wiki/Talk:Texture_Cache

(au passage vous remarquerez que j'y ai pas mal participé, en particulier en évoquant et soutenant l'utilisation du format TGA).

En parallele avec la discussion sur le format d'image stockée, il y a aussi une discussion sur la facon dont les fichiers sont indexés/stockés. Une source de problemes venant du "nettoyage" de la base de stockage des textures, il est evoqué l'idée d'utiliser une autre facon d'organiser le stockage des textures. Anfin d'eliminer, sinon diminuer, ce probleme de nettoyage/maintenance.

Fin de la partie 2, j'ai essayé de faire court, si si.

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 8 Juin 2008

Pour ceux qui ont eu la patience de lire l'article precedent jusqu'au bout, il se seront peut etre demandé : "Ok, c'est bien joli tout ca, mais elle est ou la texture dans tout ca ?"

Et bien elle n'y est pas. Enfin, pas la en tout cas.
Ce fichier texture.entries est un fichier très simple, petit (assez petit pour etre stocké en permanence en memoire pendant l'execution de SL) et donc... rapide a utiliser.

Dans secondlife la vitesse d'execution est importante, ca rame deja assez comme ca non ?
Ce fichier est simplement un index qui est tenu a jour par le logiciel pour repondre rapidement a : "Est ce que la texture que je dois afficher sur ce prims est stocké dans mon cache, ou est ce que je dois la telecharger depuis les serveurs de secondlife ?".
Avoir un index des fichiers present dans le cache est donc tres utile et doit etre rapide.
Et avoir un fichier du type de celui du precedent article EST rapide, simple, leger, donc efficace :)


Mais au final ? Ou est la texture ?
C'est ... compliqué.
Linden Lab aurait put appliquer la methode suivante :
- un fichier qui indexe les textures cachées sur votre disque dur.
- un ou plusieurs repertoires contenant les dites textures.

Mais du coup les fichiers seront des textures directement lisible, editables avec photoshop et pouvant etre reuploader dans SL. Et ca va pas du tout du tout ! Parce que les fameuses textures qui sont stockées sur votre disque dur, dans le cache, ne sont pas forcements (et meme pratiquement jamais) des textures sur lequelles vous avez les droits de copie/modification/transfert. Hors, s'il y a un moyen de les recuperer puis les reuploader, vous vous retrouvez avec des textures full perm, a votre nom, dans votre inventaire. Horreur, scandale, abomination, vol de contenu, emeute et 5000eme mort annoncée de SL et son economie.

Vous connaissez la musique je suppose ? ;)
A propos de musique justement, Les majors de l'industrie du film et du disque depensent des millions, peut etre même des milliards afin de tenter de proteger les contenus. Sans succes, c'est peine perdue. Et bien c'est pareil dans secondlife. Quelle que soit la methode il y aura toujours moyen de "voler des textures", en utilisant le cache, ou par d'autres moyens (comme les recuprer dans la memoire video de la carte graphique par exemple).

Ce que font les majors, et ce que fait secondlife, c'est "la securité par l'obscurité". Autrement dit il font en sorte que le contenu a proteger soit stocké d'une facon qui rend compliqué le "vol". Par la cryptographie ou par d'autres moyens.

Linden Lab n'utilise pas la cryptographie car c'est lent et consommateur de precieuses ressources CPU. (on en a jamais trop avec SL).

A la place, ils stockent les textures d'une facon un peu bizzare... que je ne detaillerai bien evidemment pas.
Grosso modo il y a un fichier contenant les 600 premiers octets (a quelques details près ;) ) de toutes les textures stockées. Tous entassés les un derrieres les autres. (s'il y a 100 textures, ca fait un fichier de 600*100bytes (a quelques details pres, encore))

Une serie de fichier dont le nom est l'UUID de la texture, et qui contient la texture elle-meme *moins* les 600 premiers bytes (a quelques details près) qui sont, eux, stocké dans le gros fichier cité juste au dessus.

Un ficher permetant de savoir a quel endroit du gros fichier se trouvent les 600bytes qui interessent. Car il n'est pas possible de retrouver l'UUID de la texture directement dans le premier fichier, simplement parce que ca serait "trop simple" de les recuperer. Sans ce 3eme fichier, le 1er fichier est un gros tas de n*600bytes completement inutilisables.

C'est pour cela que quand on ouvre le ficher de texture directement dans photoshop, il n'arrive pas a l'ouvrir, car il manque (a quelques details pres) les 600 premiers bytes du fichier, qui se trouvent etres les plus importants car il contiennent les "entetes" qui permet a photoshop de decoder le format j2c puis de l'affichier.

Ce n'est pas si difficile que ca que d'assembler tout ca, et de finir avec une texture utilisable. Et d'avoir au final reussi a "voler" une texture. Ca demande de savoir programmer, de prendre le temps de defaire les sacs de noeuds que Linden Lab a mis en place pour rendre la chose plus difficile et de ... vouloir le faire.

Et, visiblement (et j'en suis heureux), ce qui peuvent le faire ne veulent pas perdre du temps a voler des textures.
Et ceux qui voudraient bien, n'en n'ont pas le talent (ca c'est pas une surprise) ;)

Au final, est ce que ce sac de noeud ne ralenti pas le systeme de cache ?
Un peu, tres peu, car la plus grosse partie du temps n'est pas dans la recherche/assemblage de la texture, mais dans le format de compression utilisé. Le format j2c est tres pratique, très bien, mais... lent a decompresser. Et c'est cette decompression qui prend la majorité du temps.
Aucun interet a rendre la recherche/assemblage du fichier 2x fois plus rapide si 99% du temps est passé dans la decompression du format j2c. Il faudrait plutot optimiser la decompression, mais la... C'est deja optimisé a mort.



Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 6 Juin 2008

Bonjour,

j'ai pris la décision toute personnelle de me retirer du programme "community gateway" et du devant de la scène de la communauté francophone. Ce n'est pas tant Linden Lab que toute une série de comportements et d'évènements qui m'ont fait prendre cette décision.

Je vais faire mon possible pour conserver tout ce qu'on a créé ces 2 dernières années. Essayer de voir avec les owner francophones et autres "grands acteurs" ( ) s'il est possible de parvenir a un accord pour conserver les principales sims. Dans le cas contraire, si on n'arrive pas a s'entendre, les sims seront vendues au détail sur le marché des sims de 2nd main. Un repreneur unique de toutes les sims serait bien sur une situation idéale.

Perso, je vais retourner aux sources : scripting, coding, et administration systeme. (conception de logiciel, de serveurs, et la Francogrid).

Tout cela ne sera pas fait dans l'urgence, donc inutile de paniquer pour ceux qui ont du terrain chez moi.

Je ne m'abaisserai pas a designer des coupables ou a regler mon linge sale en public, ni a me la jouer "après moi la fin du monde". Ce n'est pas le plaisir sadique de le faire qui me manque, mais ca ne desservirai personne, et surtout pas moi. Je suis simplement fatigué de jouer les don-quichotte et j'en suis le seul responsable. Je m'en vais retourner a des activités lucratives et bien plus reposante.

Je reste dans secondlife, mais en simple resident.

Merci tous ceux qui ont rendu ce monde possible et vivant pendant les 2 plus longues et difficiles années de ma vie.
Merci à tous ... et mort aux cons. 

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 28 Mai 2008

... et au dela !


Beau comme ma 10ème opensim.

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 26 Avril 2008

Voila voila, j'etais a la conf avec Philip Linden, la team d'octane (Lewis PR), des blogeurs et blogeuses, des residents, des chefs d'entreprises SL.

Le bilan est positif.
On n'a rien appris, mais on ne s'attendai pas a apprendre quoi que ce soit.Aucune revelation bien sur.


Parmis les bon points, entre autre, Philip a decouvert qu'il y avait effectivement une communauté francophone presente et active. Il ne s'attendai pas a "autant de monde" et il en fut agreablment surpris.
On lui a reservé un bon accueil et on n'a pas été trop penible du genre "oulala ouin ouin bouh caca".

L'hotel "kube" ou on etait a vraiment un style "très secondlife" et c'est toujours sympa.

A ma grande surprise, je n'ai eu aucurn probleme a comprendre son anglais. J'ai même discuté avec lui en anglais, et je m'en suis sorti ;)


Par contre, la ou je suis decu, c'est que ce meeting etait surtout une tres bonne excuse pour discuter entre residents et qu'on n'en a pas du tout profité. Quand Philip est parti, on est tous parti, merci, au revoir. Un beau gachis.


Mais la communauté secondlife en france existe, et on n'est pas des barbares ;)

Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0

Publié le 24 Avril 2008

Oui, oui, ... pour ceux qui lisent le blog de http://www.david-castera.com/ ,j 'ai odieusement repompé le titre de son post. Et pour ceux qui ne le lisent pas : "j 'ai odieusement repompé le titre d'un post de http://www.david-castera.com/  "

Voila.

Ce qui veut dire... je suis aussi invité a aller écouter religieusement ce que va dire Philip Linden, de passage a Paris.
J'ai ne sais pas trop ce qu'on va y entendre, ni vraiment ce qu'on pourrait lui demander.... Je crois que ma seule question sera "Avez vous toujours prevu d'ouvrir les sources des serveurs ? Avez vous toujours prevu d'autoriser l'hebergement de serveurs tierces sur la grille principale ? Si oui, quand ?". Si Linden Lab doit garder le monopole de la grille, Second Life n'a plus qu'un interet limité pour moi.


Voir les commentaires

Rédigé par kerunix Flan

Publié dans #Secondlife

Repost0