[Valerie Fratica]

Euh....
j'ai entendue parler de la limitations pour les sans info de paiement mais maintenant on parle aussi de limitation au premium ?

"L'une des solution serait de mettre en place la fameuse limitation des comptes basique au login lors des pics de connexion (en gros, seul les compte premium seront capable de se connecter a la grid dans ce genre de cas)." dixit Annya.

La je ne suis pas du tout d'accord. Autant je peux comprendre pour les infos autant obliger a prendre un abonnement.... Car en dehors des 300l$ par semaine et le droit d'acheter sur un mainland ca apporte pas grand chose un Premium pour 10$/mois.
Mais il me semble que c'est une erreur de traduction de l'info
"The promised use of limiting logins of non-verified accounts during peak load has been severely lacking. This would be an effective interim solution to load issues, but Linden Lab seems unwilling to use it."
mais mon anglais est trés vache espagnole.

[Annya]

non valerie, comprend par la basic account en tant que no payment info used alias non-verified.
J'ai IM le créateur de la lettre et je te confirme mes dires.

*dit rarement quelque-chose d'aussi grave sans prendre un minimum d'infos*

[Valerie Fratica]

Je ne signerais pas une telle demande alors et beaucoup de sim privées vont s'arracher les cheveux. Car c'était un de leur gros intérêt de pouvoir proposer des terrains sans premium !

[Annya]

Il faut relativiser miss (oula nerveuse toi depuis quelques post ^^) on parle de pics de connexion qui amènerais ce cas particulier, de plus c'est une demande assez ancienne. ça ne veut pas dire que LL le fera et ils ne semble pas, tout du moins pour l'instant, en être question.

Maintenant ne pas signer juste pour ça... a toi de voir . Il y a autre chose et ceci n'est qu'une lettre ouverte qui serait en tout état de cause amener a être modifier si et seulement SI Linden Labs y accorde plus d'intérêt.

*masse les épaules de Valerie "laaa respire"*

[Antcrist]

De toute façon, il faut bien penser que comme il y a des comptes payants et non payants, il va bien falloir a linden, a un moment ou a un autre, quand les systèmes seront saturés, de limiter l'accès a la grille, il est tout naturellement logique, si il doit y avoir une limitation des connexions , de privilégier ceux qui payent, moi, ça ne me choque pas...
Je parlerais même du fait de l'usage abusif de certains comptes basic, qui passent leur vie sur un chaise, on va pas me dire que ce type est pas un deuxième compte utilisé pour faire du pognon...
Fini le camping passif, tous au slego ...
qu'ils commence par limiter les connexions des campeurs, au profit des "vrais" , j'entends actifs, joueurs ...
je suis sure qu'il y a facilement moyen de gagner de la charge serveur...

[Polo Slok]

Citation :

Publié par Antcrist

Je parlerais même du fait de l'usage abusif de certains comptes basic, qui passent leur vie sur un chaise, on va pas me dire que ce type est pas un deuxième compte utilisé pour faire du pognon...
Fini le camping passif, qu'ils commence par limiter les connexions des campeurs, au profit des "vrais" , j'entends actifs, joueurs ...
je suis sure qu'il y a facilement moyen de gagner de la charge serveur...

C'est pas faux !!! même si des fois ça dépanne !!! disons limiter ce genre de choses dois être possible !!! c'est à LL de décider et de prendre de bonnes décisions !!!

Bon jeu tout de même !!!

[DD Ra]

"The promised use of limiting logins of non-verified accounts during peak load has been severely lacking. This would be an effective interim solution to load issues, but Linden Lab seems unwilling to use it."

Le texte dit (texte entre parenthèse ajouté pour expliquer :

L'utilisation promise de la limitation du log_in pour les comptes non vérifiés (sans aucune information de payement) à manqué. Ceci serait une solution temporaire aux moments de surcharge de la grille, mais Linden Labs semble ne pas vouloir l'utiliser."

On parle donc bien de limiter l'entrée de SL à ceux qui ont inscrits leurs info de payement (comptes vérifiés) qu'il ai payé ou non, et ce en ça de forte surcharge de la grille seulement. Mais de facto TOUTS les propriétaires de terrains ont donnés leurs info de payement.

De fait Linden Labs veux le beurre et l'argent du beurre : attirer un max de gens dans SL, mais sans pour l'instant avoir ou se donner la capacité à gérer la charge.

On en revient toujours au même soucis, la restriction d'accès en cas de forces majeures, annoncée il y a trois mois mais jamais mise en place. Mais dire que cette restriction corrigerait tous les problèmes est un raccourci un peu rapide, il y a aussi beaucoup de débugage a faire (notifications, attachements...).

Le townhall avec Cory Linden est prévue à 21h (heure de Paris) Jeudi soir pour les personnes intéressées. Le lieu de la réunion n'a toujours pas été donné.
Vous pouvez poser votre question à partir d'une nouvelle section du forum officielle créée spécialement à cette occasion (mais votre question ne sera pas forcément choisie) : http://forums.secondlife.com/forumdisplay.php?f=341

[buttbadger Mirabeau]

J'ai signé, dans l'espoir que les lindens cesseront de dire "Nous avons trouvé un bug concernant <mettez ici un bug banal et qui gène la bonne marche de SL> et nous allons nous efforcer de regler ce problème au plus vite, merci de voter patience" pour dire "On a trouvé un problème sur la Grid et on va attendre que ça passe ou que les plaintes en bug reports dépassent les 100 000 pour agir"

Comme beaucoup de joueurs francophones ont signé la pétition et puisqu'une réunion se tiendra ce soir à 21h à Pooley Stage sur ce sujet avec Cory Ondrejka, Chief technology Officer de Linden Lab, je retransmets la réponse officielle à la pétition.

J'anticipe les critiques: je ne fais que transmettre, je ne défends en aucun cas la politique de cette société.

Citation :

Publié par Cory Linden

Je tiendrais une réunion aujourd'hui pour parler des problèmes de stabilité et de performance cités dans la pétition (Project Open Letter) et dans les nombreuses questions du forum. Dans ce post, je reviendrais sur quelques questions données dans la lettre mais déjà deux commentaires.

D'abord, merci pour votre travail sur la pétition. Nous essayons de maintenir des canaux de communication performants et d'un point de vue du développement, une liste claire des problèmes.

Deuxièment, je regrettes les problèmes que vous rencontrez. Je suis conscient du temps et de l'énergie que vous mettez dans Second Life et je fais tout en mon pouvoir pour m'assurer que Second Life est ce que vous voulez que ce soit.

Les pertes d'inventaire

L'inventaire et les autres donnés spécifiques sont distribués sur de multiples bases de donnés MySQL que nous appelons les serveurs inventaire (inventory servers). Nous avons choisis ce nom puisque beaucoup de donnés inventaire sont stockées ici. Cette structure en partitions permet une extensibilité pour plus de donnés mais nécessite un rééquilibrage manuel après des périodes de croissance et de charge de Second Life. Les scripts qui gèrent ce rééquilibrage de la base de donnés, bien qu'ils furent âprement testés et utilisés pendant plus d'un an, ont un bug sérieux dans leur fonctionnement. Avec pour conséquence des inventaires endommagés pendant leurs transferts. La bonne nouvelle est que ce bug a été corrigé et de nouveaux scripts de transfert sont utilisés.

Il existe d'autres erreurs qui peuvent aboutirent à une perte d'inventaire, comme des blocages des bases de donnés, un échec dans les transactions, un échec dans la mise en cache de l'inventaire (uniquement la liste, pas les objets) sur le client, ou l'impossibilité pour le système de fournir une donné relative à un inventaire (je crois qu'il doit s'agir des "missing from database").
Deux équipes indépendantes travaillent sur ces problèmes et de nombreuses corrections sont déjà sortis ou en développement. La première équipe se concentre sur les bugs existants, tandis que la seconde équipe s'attelle à la création d'un système de transaction plus robuste. Nous revoyons aussi le design avec des développeurs extérieurs familiers des systèmes de transactions. Alors que nous avançons dans ce processus de transaction nouvelle-génération, nous publierons ces spécifications en même temps.

Les limites d'inventaire

Nous n'avons aucun projet en cours pour limiter la taille de l'inventaire même si cela fut discutée. Nous avons étudié une grande quantité de donnés afin de prendre de meilleurs décisions pour:
- savoir où placer la limite de l'inventaire
- anticiper les achats d'équipements (serveurs)
- comprendre comment l'inventaire est utilisé.
Il faut aussi noter que la taille de l'inventaire n'est pas la cause des problèmes rencontrés, sauf dans une certaine mesure parce que de gros inventaires nous obligent a acheter des serveurs plus régulièrement. Par conséquent, les éventuels problèmes de transfert cités plus haut touchent plus de personnes lors du rééquilibrage qui suit l'ajout d'un nouvel équipement.

La sauvegarde d'inventaire/le stockage local

Aucun projet précis de ce côté mais des bases ont été posé pour le permettre, nous pourrons ainsi démarrer ce projet rapidement à partir du 3ème trimestre. Les obstacles à sa création ne sont pas techniques mais liés à la protection et aux permissions des donnés. Si des sauvegardes et un stockage local créent des copies supplémentaires de donnés, il y a une réelle opportunité de prendre appui sur Creative Commons et d'autres licences qui autorisent la copie libre.

La liste d'amis

La liste d'amis connectés est cassée depuis la sortie de la version 1.15. Le cache du serveur gérant ces donnés fut accidentellement enlevé, créant de ce fait une forte augmentation de la charge sur le reste du réseau (backbone). Cela l'a surchargé et l'a rendu inefficace. Pour procéder au débugage, nous avons du désactiver la page web de la liste d'amis afin de diminuer la charge. Bien qu'une grosse partie du problème fut réglée la semaine dernière, un petit changement dans l'interface de programmation (API) l'avait de nouveau cassé. Le problème fut finalement corrigé hier.

Malgré toutes ces corrections, un bug persiste si le client ne reçoit pas les statuts des amis lors de la connexion. Comme les statuts sont sauvegardés et uniquement remis à jour à ce moment-là, cela signifie que tant qu'un ami ne s'est pas connecté ou déconnecté, son statut n'est pas correct. Nous traquons ce bug et toute information supplémentaire ou test nous aiderait grandement sur JIRA.

A long terme, les statuts sont un autre projet que nous améliorons. Une grande partie de notre nouveau design est la présence, et comme pour les transactions, nous revoyons actuellement celui-ci avec des experts extérieurs qui ont construit des systèmes similaires.

Recherche

Nous avons un crash intermittent dans MySQL lié aux requêtes Recherche. La fonction Recherche est affectée de façon sporadique à cause de ce crash. Nous suivons le problème mais avons été incapables de le résoudre jusqu'à présent, puisque la requête en question est le plus souvent saine. Nous sommes aussi au milieu d'un passage à MySQL 5.0 sur l'ensemble des infrastructures. Comme la version 5.0 dispose d'une meilleure information sur les bugs, nous espérons que le bug sera trouvé.

De plus, améliorer la fonction Recherche est un projet majeur pour le 2ème trimestre. nous pensons que c'est important pas seulement parce que cela améliora la vie des résidents mais parce qu'aujourd'hui Recherche occupe une base de donnés MySQL centrale. Tandis que nous améliorons la fonction Recherche, nous créons aussi une solution plus extensible. Plus de détails sur Recherche seront donnés bientôt.

Stabilité et performance de la grille

Les problèmes de téléport et d'inventaire ne sont pas liés à Havok (moteur graphique) ou Mono (moteur des scripts). Si les deux amélioreront les performances et la stabilité des régions, ils n'ont pas d'impact appréciable sur les problèmes du réseau. Havok 4 sera en test sur le Beta grid et les principaux blocages sur Mono ont été réglé. Nous attendons plus de ressource pour les lancer.

Les échecs de téléport peuvent être le résultat de plusieurs problèmes différents et sont exacerbés par les problèmes de statut. Une équipe est chargée d'enquêter là-dessus. Encore une fois, des donnés supplémentaires et des reproductions nous aideraient beaucoup.

Les outils de construction

Notre studio se concentre sur les problèmes directement sur la grille et tente de les reproduire. Il est évident que les outils de construction sont indispensables à la création de contenu et nous avons l'espoir de les corriger rapidement.

Du point de vue de l'ensemble de nos efforts de développement, quatre de nos studios internes travaillent sur les problèmes donnés dans cette pétition. Actuellement, sur les 54 employés du développement, du program management, QA et Web développement, 37 travaillent directement sur ces problèmes, ou 69%. Nous avons engagé 5 nouveaux développeurs qui n'ont toujours pas commencé mais qui travailleront sur ces bugs,augmentant leur nombre de 42 à 59 ou 72%. Puisque toutes les taches ne peuvent être réparties équitablement entre tous les développeurs et que de nouveaux projets ont besoin d'avancer, j'estime que cela est une proportion assez importante.

J'espère que ce post répond à certaines de vos questions et j'en parlerais plus ce soir.

[Seb Neox]

En fait il voit les choses encore plus en noir que nous lui.