Journal Une histoire de fork

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
71
21
août
2012

Sommaire

NdM : Le journal a été transformé en dépêche.

Dans un récent journal, il a été fait état du problème des forks dans les jeux libres… Mais, plutôt que de tirer des conclusions sur des suppositions, et si nous étudions un exemple concret ? Alors, voici une histoire de fork !

Je propose une rétrospective historique avec une petite analyse et quelques avis personnels.

Quake Ⅲ Arena, ioQuake3

En décembre 1999 est sorti le Jeu Quake Ⅲ Arena créé par id Software.

Six ans plus tard, en août 2005, le moteur de Quake 3 est libéré. Le code de Quake 3 est repris par l'équipe d'icculus pour donner le moteur ioQuake3. Cette ouverture et publication du moteur ioQuake3 est pour de nombreux mods l'occasion de sortir en version standalone.

Tremulous

C'est le cas de Tremulous, un jeu passionnant qui propose deux classes d'ennemis différentes, les humains et les aliens, ce qui permet au jeu de se distinguer de la majorité des quake-like qui permettent seulement de se battre contre son semblable. En plus de cette spécificité, il rajoute à la partie « jeu de tir en équipe  » toute une partie de gestion stratégique avec la capacité de construire, organiser et déplacer la base. Une équipe ne gagne pas parce qu'elle a fait le plus de frags, mais parce qu'elle a détruit la base adverse, empêchant les joueurs de venir combattre.

Tremulous sort donc en version standalone à l'occasion de sa sortie en version 1.1.0, en mars 2006.

Malheureusement, c'est aussi la dernière version sortie. Une version 1.2.0 est attendue et promise depuis 2006 mais n'a encore jamais vu le jour. Puisqu'il n'y a pas eu de sortie officielle après la 1.1.0, les dépôts proposent toujours la 1.1.0.
Si l'on me proposait de remonter le temps, j'en profiterais peut-être pour essayer de convaincre l'équipe des bienfaits du release early, release often.

Dans les faits, depuis très longtemps, plus aucun serveur ne tourne en version 1.1.0. Se connecter avec un client 1.1.0 provoque un avertissement. Tous les administrateurs de serveurs ont installé des compilations de la branche de développement, rendue facilitée par la publication de quelques binaires précompilés sur des serveurs plus ou moins officiels. Si vous vous connectez sur des serveurs actuels avec un Tremulous 1.1.0, certains vous indiqueront un lien pour télécharger une mise à jour, chaque fois différente (par exemple l'un m'a indiqué celui-ci)… Parfois en allant à ces liens (par exemple un autre serveur m'a indiqué ce lien, qui propose tout simplement TremFusion).

Donc voilà l'état de Tremulous aujourd'hui : la seule version publiée est la 1.1.0, il y a six ans. Plus personne ne joue avec et tous les serveurs râlent si vous vous connectez avec. Si vous êtes un joueur débutant, vous commencez la partie par un message d'erreur peu accueillant.

Un exemple de bug dans Tremulous qui n'a toujours pas été corrigé en six ans : le menu de configuration n'est accessible que depuis une partie ! Il faut donc rejoindre un serveur ou lancer une partie en local pour changer son pseudo, sa résolution d'écran…

Il ne fait pas bon être débutant sous Tremulous, il faut franchir une marche assez élevée, ce qui fait que petit à petit les joueurs se sont mis à jouer entre eux en cercle fermé. D'autres problèmes interne à la communauté de joueurs ont provoqué la migration de certains joueurs vers d'autres jeu, comme UrbanTerror proposant pourtant un GamePlay plus classique.

Une bêta de la 1.2 « Gameplay Preview » est sortie en 2009, mais cela n'a pas freiné le départ des joueurs.
Cela fait désormais 6 ans que Tremulous 1.1.0 est sorti et qu'on attend une sortie officielle. 6 ans, c'est le temps qu'à attendu id Software pour considérer leur moteur de jeu comme non rentable et dépassé, pour pouvoir le libérer.

Le fork Tremulous

Tremulous utilise un fork du moteur ioQuake3. Tremulous est donc plus qu'un mod collé à ioQuake3, c'est aussi un fork.

Les mods de Tremulous

Tremulous, comme beaucoup de jeux, a été modé. Mais il faut voir que beaucoup de ces mods n'étaient là que pour corriger des défauts de Tremulous, ou pour apporter des améliorations qu'on aurait bien aimé voir dans une version 1.2.
Déjà, l'existence de ces mods traduisaient un besoin non satisfait : que l'équipe de Tremulous publie une mise à jour.

On peut par exemple citer le mod TremX, et son annonce sur les forums tremulous donne une petite idée de l'ambiance, les premiers mots sont « some minor(!) fixes », le point d'exclamation étant assez explicite. Le reste de l'annonce parle du dépôt svn du moteur et sentait déjà le fork, TremX est sorti pour la première fois en août 2006.

Un autre mod populaire était le mode KoRx, dérivé de TremX, KoRx pour tremx-kor, kor pour le nom de l'équipe Knights of reason.

Dans le genre « mod qui corrige les bugs », Ergo+ ne changeait rien au jeu, mais apportait quelques corrections pratiques comme placer le menu d'option sur la page principale.

Le moteur XreaL

XreaL est un fork du moteur ioQuake3, et était le moteur libre le plus avancé avant la libération du moteur de Doom3. En fait, je ne saurais pas comparer le moteur de Doom3 et XreaL et dire en quoi l'un est meilleur que l'autre. Ce qui est certain, c'est qu'XreaL est un moteur très avancé, et propose des améliorations graphiques modernes, et la prise en charge de formats plus récents que ceux de Quake3 (notamment les formats de Doom3 et une partie des formats d'Unreal Engine).

XreaL avait son site dédié, xreal-project.net (un site parking, PAKILIKAI !) mais le site a fermé quand Wolfenstein : Enemy Territory a commencé à migrer sur XreaL, peu après la libération du code d'Enemy Territory, tandis qu'XreaL intégrait des parties d'iowolfet.

Avant l'aventure ET:XreaL, XreaL était plus qu'un moteur de jeu, c'était aussi un projet de jeu libre, mais pas grand chose de plus qu'un classique QuakeLike sans grand intérêt.

Aujourd'hui, la page officielle semble être sur ModDB. Le dépôt se trouve sur Sourceforge, et la lecture du Readme semble montrer que désormais XreaL est avant tout le moteur d'ET:XreaL.

XreaL et Tremulous

Dès que XreaL a commencé à être connu, certains ont imaginé et essayé de porter Tremulous dessus. Il est en effet beaucoup plus simple de porter un jeu depuis ioQuake3 vers XReaL que de porter vers ioDoom3 ou ses forks.

Avant que XreaL ne devienne le moteur d'ET:XreaL, on pouvait compiler XreaL pour tremulous avec un simple argument à make (je n'ai pas vérifié depuis).

Le fork TremFusion

TremFusion est à l'origine une fusion de plusieurs mods de Tremulous.
C'est devenu un fork, et je pense que pour beaucoup de joueurs, il correspond à la version 1.2 tant attendue et jamais sortie.

Tremfusion 0.9 est sorti en décembre 2008, la dernière version, Tremfusion 0.99r3, est sortie en 2009. Il n'y a pas eu de mise à jour depuis, peut-être parce que ce n'est pas vraiment nécessaire, et en attendant d'autres projets plus ambitieux (voir ci-après), il faisait au moins ce qu'on attendait de lui : corriger les bugs du moteur et apporter les améliorations de gameplay que l'usage demandait.

TremFusion ne remplace que le moteur de Tremulous, par exemple le dépôt PlayDeb vous installera le paquet tremfusion et tremulous-data, et vous verrez les mêmes serveurs que Tremulous. Si vous n'avez pas de dépôt qui propose TremFusion pour votre distribution, il faudra installer Tremulous avant TremFusion.

Tremfusion et XreaL

L'équipe de tremfusion avait essayé de le porter sur XreaL, il existait une branche TF-XreaL.
Aujourd'hui tremfusion ne tourne pas sur XreaL, il semble plutôt que le code de tremfusion est toujours le code de tremulous, plus des correctifs, plus quelques fonctionnalités rapportées d'XreaL.

TremZ et OpenWolf

TremZ est à l'origine un mod de tremulous qui a très vite viré au fork, lui aussi. Le projet TremZ a forké le moteur XreaL pour en faire le moteur OpenWolf.

Le projet OpenWolf était très ambitieux : devenir le moteur libre qui remplacerait ioQuake3 dans les projets utilisant ioQuake3 actuellement, et le développeur publiait régulièrement des copies d'écran d'OpenWolf faisant tourner Tremulous, Urban Terror et Enemy Territory. Le but premier n'étant pas seulement d'être le moteur de TremZ, mais également de pouvoir faire tourner les autres jeux sans modification. On pouvait lire sur le forum :

Project goal is to provide perfect combination between current IDTech3 engines (Urban Terror, Quake3, Return To Castle Wolfenstein, Enemy Territory and Tremulous).

On pouvait lire aussi :

One of the major goals is to be able use assets from any Quake 2 or 3 mod game. So, being able to play regular Tremulous 1.1 on OpenWolf would be a proof of this capability.

Le moteur était très prometteur, cette vidéo montrant les effets d'eau m'avait beaucoup impressionné, et on peut lire une ancienne description du moteur assez intéressante (mais semble mélanger fonctionnalités effectives et souhaitées).

Cependant, il y eut des dissensions assez vite.

Le développement est devenu fermé, ce n'est pas incompatible avec le libre, ils ne sont pas obligés de développer collaborativement, ils ont seulement obligation de publier les sources des binaires qu'ils publient, et pour le moment aucune alpha n'a été publiée. Il y avait le dépôt github.com/TremZ, mais il n'existe plus.

On peut lire les motivations sur le forum de TremZ. Il en ressort des arguments similaires à ce qu'on a pu lire pour Warsow.

Cependant, à l'inverse de Warsow, et comme Tremulous, les données devraient être publiées sous une licence Creative Commons (mais je ne crois pas avoir lu laquelle), le but est toujours de faire un jeu libre.

Le but du projet TremZ est de sortir un jeu bon du premier coup.

TremZ a donc pris résolument la direction d'un développement en mode cathédrale, allant dans la même direction que l'équipe de tremulous et en prenant donc les mêmes risques. Il était prévu une première diffusion en décembre en disant « vous avez attendu 6 ans que tremulous 1.2 sorte, voici TremZ », mais rien n'est sorti, et on attend TremZ comme on a attendu tremulous 1.2. Et à part un poisson d'avril, il n'y a plus de nouvelles sur le blog officiel. Sur les forums, il y a encore quelques discussions, mais pas grand chose de plus que des copies d'écran et des comparaisons entre TremZ et Unvanquished.

Unvanquished et Daemon

En fait, TremZ a été forké par ceux qui n'étaient pas d'accord avec cette politique de développement fermé, la majorité des participants est partie d'elle-même, certains se sont faits bannir du projet TremZ.

Unvanquished était un des noms pressentis pour TremZ, en fait le dépôt TremZ de github cité plus haut est devenu le dépôt d'Unvanquished, et a gardé ce nom après le fork jusqu'à ce qu'une première sortie alpha soit faite (et donc que le nom soit fixé). Le code d'Unvanquished ainsi que de nombreux travaux complémentaires est disponible sur github.com/Unvanquished.

Du côté de TremZ, je n'ai lu aucune remise en question, si ce n'est de reporter la faute sur le principe même du modèle Open Source :

Yes, also welcome to opensource development things like this happen all the time. It isn't as a big of a deal as you think, don't over think it.

La pre-release annoncée par le projet TremZ a en fait été sortie par le projet Unvanquished. Depuis décembre, ils ont déjà sorti 6 versions alpha, la dernière est sortie le 3 août dernier.

De son coté, le projet TremZ reconnaît intégrer les corrections de Daemon à OpenWolf, mais ne permet pas encore (tant qu'ils ne publient rien) l'inverse. Ils en ont le droit.

Le projet Unvanquished prend donc la direction d'un projet, non seulement libre, mais ouvert et communautaire, et fait le choix d'avancer par petites incrémentations.

Analyse

À propos du fork de jeu libre

Dans l'argumentaire de TremZ, il est dit que pour un jeu vidéo, c'est dangereux de publier trop tôt des versions non finies, car le public du jeu vidéo peut rester définitivement déçu par l'expérience d'une simple version alpha. C'est quelque chose de vrai.

Pourtant, pour une fois, l'argument ne tient pas. En effet, TremZ/Unvanquished sont des forks de Tremulous, ils s'adressent donc à une base de joueur déjà convaincue ! Il suffit seulement de ne pas faire pire que Tremulous pour ne pas perdre de joueurs, et d'apporter plus que Tremulous pour les récupérer. C'est ce qu'a fait TremFusion, les joueurs de Tremulous ont peu à peu migré vers TremFusion, ils migreront peu à peu vers Unvanquished.

Dans le débat sur les licences de Warsow, et dans les discussions du forum TremZ, il a été avancé que le développement libre nuisait aux projets de jeux libres en dispersant la communauté de joueurs. À première vue, l'exemple de Tremulous semble aller complètement dans ce sens. En creusant un peu plus, on se rend compte que le problème est ailleurs, le fork étant seulement ce qui révèle un problème.

Et si nous regardions vite fait les autres projets libres similaire ?

  • Nexuiz a forké une fois, mais c'est un cas particulier : il a été vendu à Illfonic et est devenu propriétaire. Le Nexuiz libre est devenu Xonotic, pour les joueurs, cela n'a rien changé, si ce n'est le nom. La base de joueur n'a pas été dispersée, ni la base des développeurs.
  • Personne n'a forké Smokin'Guns ou AlienArena (ou alors c'est vraiment confidentiel). Pour Smokin'Guns, ils sont revenus d'un fork de Quake3 vers la version ioQuake3.
  • OpenArena a vu quelques forks qui n'ont pas fait long feu, qu'on ne peut pas accuser de diviser la communauté et qui ont surtout été des explorations de concept qu'autre chose (comme IHTG qui visait à proposer une version du jeu pour systèmes peu puissants).

Il n'y a vraiment que le jeu Tremulous pour avoir vu autant de forks dans son histoire, alors on ne peut pas dire que ce n'est pas la liberté qui est cause de ces forks, mais un problème inhérent à la communauté de Tremulous.

Le fork est un marqueur, la plupart du temps, il y a fork quand quelque chose ne va pas. Pour tremulous, ce fut de ne pas savoir publier des corrections et de laisser les joueurs dans l'illusion. Parce que c'était libre, alors Tremulous a été forké, Tremulous est encore en vie grâce à ses forks. Alors oui la communauté des joueurs est divisée, mais elle existe encore. Si Tremulous n'avait pas été libre, il n'y aurait déjà plus de joueurs, et le jeu serait complètement mort. Les forks permettent cette survie, et ce n'est pas un inconvénient !

En fait, les jeux libres forkent pour survivre. Ils ne forkent pas juste pour diviser. Quand un jeu libre forke, c'est qu'il est déjà pourri.

Il y a deux types de forks dans les jeux libres :

  • le fork pour survivre
  • le fork pour explorer une nouvelle idée

Aucun des deux n'est mauvais : le premier est une chance, le second ne porte pas préjudice : il commence souvent comme un mod (et alors ne divise pas la communauté des joueurs), et s'il n'est pas intéressant, il meurt très vite. Si le mod/fork survit, c'est qu'il était pertinent, et c'est encore une chance d'avoir un nouveau jeu. On ne joue pas toute sa vie aux mêmes jeux, et certaines variations sont très appréciées jusqu'à supplanter le jeu original, au grand plaisir des joueurs, et puis les développeurs du jeu original peuvent toujours rejoindre le nouveau jeu à la mode, c'est ça aussi le libre.

À propos du fork de moteur de jeu libre

Alors là, c'est un vrai problème. J'ai pour avis que beaucoup de ces jeux prennent trop souvent le risque du fork. Tremulous est un fork, Smokin'Guns fut un fork… TremZ puis Unvanquished ont forké XreaL…

Dans le milieu du jeu vidéo, il semble inhabituel de proposer ses modifications à un projet plus général. Quand on installe UrbanTerror, OpenArena, WorldOfPadman, Smokin'guns, Tremulous etc. on installe autant de fois ioQuake3 ou l'un de ses forks. Jamais personne n'a transformé ioQuake3 en une libioquake3.

Alors, je vais tenter un avis et prendre beaucoup de risque… mais ça semble venir du fait que la majorité des dévelopeurs sont sous windows et ne connaissent pas la joie d'un dépôt. Un développeur sous windows, il fournit toujours toutes ses dépendances, et d'une certaine manière c'est comme s'il forkait à chaque fois. Sous Windows quand vous installez Gimp, Pidgin et Gsmartcontrol, vous installez trois versions de GTK, et chacun de ces projets vous fournit sa version de GTK. On comprend qu'il soit normal pour un développeur sous Windows de fournir une version supplémentaire d'ioQuake3, et qu'il devient alors très tentant de forker quand il n'est pas naturel de remonter upstream ses modifications et de fournir un paquet dépendant d'un autre paquet développé par une autre équipe.

Aussi, le développeur propriétaire, très courant sous Windows, fournit tout d'un bloc parce que l'utilisateur ne peut pas se procurer les dépendances. Bref, j'ai l'impression que tous ces forks sont plus ou moins la conséquences des habitudes de développement propre au monde propriétaire et/ou à la plate forme Windows.

On pourrait comparer cette situation avec l'exemple (ouhouh, l'appeau à troll) des projets Mozilla : ils ne sont pas vraiment conçus dans l'idée que XulRunner puisse être livré séparément, et les projets comme Debian ont du mal avec ces projets, la manière de faire n'est pas du tout celle de procéder habituellement dans le libre, ça convient tout à fait à un programme Windows (et l'on ne peut pas faire le reproche d'avoir comme base principale d'utilisateur des utilisateurs de Windows), mais ça entraîne quelques complications. Par exemple, un projet basé sur XulRunner, BlueGriffon, vient encore avec sa propre version de XulRunner… Sous Windows, ça ne choque pas ; pour beaucoup de distributions Linux, c'est une mauvaise manière de faire.

On pourrait avancer (ouhouh, je prends des risques) que l'absence de gestionnaire de paquet sous Windows conditionne la méthode de travail du développeur, ce qui conditionnera au final la cohérence du produit. D'une certaine manière, l'absence de gestionnaire de paquet ne nuit pas directement à l'utilisateur, elle nuit indirectement, parce que le développeur n'en a pas.

Mais pour revenir à nos forks de moteurs de jeu, on peut reconnaître que beaucoup de temps et de ressources sont probablement gaspillés, mais là encore, l'argument du fork n'est pas recevable : les moteurs de jeu ne sont forkés que lorsque le jeu est déjà forké.

Ce n'est donc pas la possibilité du fork qui provoque le fork. La possibilité du fork n'est donc pas un désavantage. Il y a certainement plein de choses regrettables dans tous ces forks de forks de forks de moteurs de jeu, mais puisque ces forks ne surviennent qu'après coup, ils ne sont pas directement un risque pour le jeu. Ils sont un risque pour le moteur de jeu. C'est pas le fork qui est mauvais ici, c'est la manière de forker qui l'est.

Faire un jeu forkable ne signifie pas que le fork soit un jour effectif. Un jeu qui ne forke pas est un jeu dont l'équipe de développement a une ligne directrice claire et établie, et qui a un développement vivant. L'expérience montre que les jeux libres et sérieux ne forkent pas, les jeux libres qui forkent ne forkent pas parce qu'ils sont libres, mais parce qu'ils prennent l'eau.

Ce ne sont pas les forks qui ont tué Tremulous, mais c'est parce que Tremulous est mort que Tremulous a été forké.

Remarque générale sur ces forks

Les données ne sont quasiment jamais forkées, parce que justement elles constituent l'identité du jeu beaucoup plus que le moteur, c'est donc beaucoup plus risqué. Ce sont les moteurs qui forkent.

L'argument du fork est valable pour le moteur, pas pour les données.

L'avenir de Tremulous.

Je souhaite que le projet Unvanquished arrive à ressusciter ce merveilleux jeu que fut Tremulous, et c'est facile d'avoir de l'espoir parce que le développement est actif et l'équipe communique bien !

Il est très probable que le projet TremZ devienne comme la version 1.2 de Tremulous : une illusion. En plus de ne pas se rendre compte que, dans leur cas, ils pouvaient se permettre le release early, release often, et qu'ils n'ont pas saisi cette chance, en plus de ne pas savoir se remettre en cause (reporter la cause du fork sur sa simple possibilité, c'est petit), ils n'ont pas non-plus remarqué que pour un jeu indépendant qui a peu de ressource pour sa communication, c'est dangeureux de jouer à la boîte noire.

Ils disparaissent peu à peu des discussions, il leur sera de plus en plus difficile de recruter des artistes et des développeurs, et les joueurs se désintéressent.

Avec tout ça, ils ne font pas que porter le jeu, ils commencent à remettre en cause certains points du gameplay, voulant remplacer les aliens insectoïdes par des quadrupèdes… Ça rappellera à certains un récent journal qui traitait du risque et de la tentation de la réécriture… Plus le temps passe et plus ils se donnent du travail…

Il y a toujours quelques joueurs qui jouent au Tremulous original, enfin, le tremulous original avec patchs téléchargés sur un obscur serveur, si vous installez Tremulous depuis votre dépôt les serveurs râleront.

Unvanquished remplace peu à peu les modèles par des plus détaillés, voir par exemple cette galerie, certains modèles présentés sur cette page ont déjà été intégrés.

Certains serveurs proposent des bots. Surtout, il faudra faire des cartes tirant parti des possibilité graphiques du moteur, surtout que les nouveaux modèles détaillés d'Unvanquished font un peu tache dans les cartes de tremulous…

Les sons devront être refait, c'est un problème qu'essaie de résoudre le projet tremulous original, car il est apparu que les droits sur les sons étaient incertains voire complètement douteux.

Jouer ?

Donc, si vous souhaitez jouer, vous pouvez essayer TremFusion, il y a toujours une base de joueur active. Une archive pour Linux est proposée sur la page de téléchargement, et pour ceux qui sont sur Ubuntu, le dépôt Playdeb le propose.

Pour ceux qui voudraient essayer Unvanquished, un installeur pour Linux est disponible sur leur page SourceForge, et un paquet Ubuntu est disponible sur PlayDeb.

Ces jeux n'ont pas vraiment de sens sans une base de joueurs active !

  • # Commentaire supprimé

    Posté par  . Évalué à 8.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Oui ?

      Posté par  (site web personnel) . Évalué à 6.

      Bah non pas vraiment, c'est souvent plus amusant de parler des gens quand ils sont absents ! :D

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Oui ?

      Posté par  (site web personnel) . Évalué à 2.

      Ah, merci de m'avoir éclairé. Je ne comprenais pas cette histoire de fourchettes et de jeux vidéos.

    • [^] # Re: Oui ?

      Posté par  . Évalué à 3.

      Qui demandeuh le docteur?

      • [^] # Re: Oui ?

        Posté par  . Évalué à 2.

        Le docteur qui ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Oui ?

          Posté par  . Évalué à 2.

          Qui joue en première base ?

          • [^] # Re: Oui ?

            Posté par  . Évalué à 2.

            Qui est sur scène maintenant ?

  • # pas mal

    Posté par  (site web personnel) . Évalué à 5.

    C'est plutôt poussé comme analyse. Aller, j'imprime pour garder vers moi. Justement je ne savais plus où j'en étais sur ce sujet, Tremulous disparu, pas disparu? TremZ sorti, pas sorti? Unvanquished, connaissais pas.

  • # De la difficulté de maintenir un serveur.

    Posté par  (site web personnel) . Évalué à 5.

    Pour avoir administré le serveur MJTavern à l'époque je dois avouer qu'au bout d'un moment c'était plutôt coton de maintenir un serveur à sans partir sur des forks ou mods qui rendent fou les gens qui tentent de se connecter dessus.

    D'ailleurs quand j'ai voulu voir il y a quelques temps que qu'était devenu ce jeu, j'ai eu bien du mal à trouver quel fork/mod/version était la plus à jour et j'ai donc abandonné toute tentative de faire revivre ce serveur.

    Superbe analyse en tout cas.

    • [^] # Re: De la difficulté de maintenir un serveur.

      Posté par  (site web personnel) . Évalué à 4.

      Moi je jouais surtout sur Bricosoft :)

      C'est vrai que cette pagaille a beaucoup nuit à Tremulous. Un truc qui m'énervais, c'était la prolifération des maps alacon type highrise, ou les serveurs aimbot only. Bref, on ne peut pas accuser à Tremulous d'avoir péricilité parce qu'il était libre, mais parce qu'il n'était pas maintenu (= prolifération des mods et forks), qu'il et n'y avait pas de serveur officiel propre et entretenu (on ne peut pas empécher les mods rigolos pour se marrer, mais il ne faut pas qu'ils soient les seuls). Tout ces défauts peuvent être endigués dans un projet libre, c'est n'est pas un problème de liberté/propriétaire. J'espère que l'équipe d'Unvanquished saura garder l'attention nécessaire au sérieux du projet, et saura aussi maintenir un pool de serveurs propres.

      Forcément, quand les joueurs sérieux arrivaient sur un serveur UrbanTerror, ça leur changeait la vie !

      ce commentaire est sous licence cc by 4 et précédentes

  • # PadMaaaaan ! PadMaaaaan!

    Posté par  (site web personnel) . Évalué à 1.

    Y'a de nouveau une version de UrbanTerror dispo pour linux ? (la dernière fois que j'ai voulu y jouer, malgrés l'annonce, il était impossible de trouver autre chose qu'un gros exe pour Windows…)

    Donc, on s'est rabattu sur un WoP bien "sanglant"… De tous les mods de Q3A, c'est celui que je trouve le mieux fini et le plus rigolo/fun :o)

    Proverbe Alien : Sauvez la terre ? Mangez des humains !

    • [^] # Re: PadMaaaaan ! PadMaaaaan!

      Posté par  . Évalué à 3.

      Ya toujours eu une version linux de UrbanTerror depuis que je connais. La version "HD" (qui verra le jour quand elle sera prête, DukeNukem-style) est en beta et uniquement disponible pour windows.

      Sinon la version 4.2 de UrbanTerror est sortie y'a pas longtemps. La 4.2 était censée être la version HD promise depuis si longtemps, mais les devs ont décidé d'en faire une mise à jour pour faire patienter les joueurs.

      Mais bon si tu veux toujours y jouer essaye plutôt de jouer à la 4.1.1, pas grand'monde ne joue à la 4.2 car les serveurs crashent souvent et les animations des joueurs sont ridicules.

    • [^] # Re: PadMaaaaan ! PadMaaaaan!

      Posté par  (site web personnel) . Évalué à 7.

      UrbanTerror semble disponible en version 4.2beta mais je n'ai pas essayé cette version.

      L'avenir d'UrbanTerror est complètement propriétaire (et donc son fonctionnement sur la distribution que tu utilises n'es pas garanti).

      Un futur UrbanTerrorHD a été annoncé en novembre 2010 avec un argumentaire pour le moins étrange :

      Hi folks, Frozen Sand here with some important news about the next release. Firstly, Urban Terror 4.2 is still coming. It’s got new maps, new visuals, new weapons, a new renderer and of course, the passport anticheat. It’s got the most new content and features since the original 2.0. Pretty amazing seeing it was supposed to be just a nice quiet patch done sometime last year. Everybody loves feature creep, right?

      To be able to do all that, Frozen Sand is going to ship as an official Q3 licensee, forked properly from the 1.32b Quake sources. The GPL stuff we’ve made public releases of (IoUrbanTerror 4.1 and IOBumpy) will still have their sources available, but there won’t be another Q3/GPL’d Engine Urban Terror release. From the next version on out, Urban Terror will be its own standalone game with its own engine and no longer a mod. This means we can do the tech we want instead of having to keep backwards compatibility with vanilla Q3.

      Ce que je pourrais essayer de traduire par :

      Salut, Frozen Sand arrive avec quelques importantes nouvelles à propos de la prochaine version. Tout d'abord, Urban Terror 4.2 est encore à venir. Il a de nouvelles cartes, de nouveaux visuels, de nouvelles armes, un nouveau moteur de rendu et bien sûr, le système de passport anti-triche. C'est la version qui apporte le plus de nouveauté en terme de contenu et de nouvelles fonctions depuis la version 2.0 originale. C'est assez étonnant de voir que ce n'était censé être qu'un simple patch prévu pour le courant de l'année dernière. Tout le monde aime les nouvelles fonctionnalités, non?

      Pour être en mesure de faire tout cela, Frozen Sand distribuera Urban Terror sous licence officielle Q3, forkée correctement à partir des sources de Quake 1.32b. Les trucs GPL que nous avions distribués (ioUrbanTerror 4.1 et IOBumpy) auront toujours leurs sources disponibles, mais il n'y aura plus d'autre moteur d'Urban Terror distribué sous GPL. Pour sa sortie, Urban Terror sera un jeu autonome avec son propre moteur et non plus un mod. Cela signifie que nous pouvons faire de ce que nous voulons du code, sans avoir à se soucier de maintenir la rétrocompatibilité avec le moteur Q3 vanilla.

      Je dis bien pour le moins étrange parce que la raison du passage au propriétaire est celle de pouvoir forker et ne plus être un mod.
      La première fois que j'ai lu cette nouvelle j'ai vraiment cru à un poisson d'avril, sauf que ce n'était pas le 1er avril…

      Je ne sais pas si des gens leur ont fait remarquer qu'ils avaient le droit de forker ioQuake3, surtout qu'ils étaient quasiment les seuls à ne pas l'avoir vraiment fait ! Effectivement, même en livrant UrbanTerror avec ioQuake3 pour ne pas nécessiter Quake3, le jeu enregistrait toujours ses préférences dans ~/.q3a/q3ut4 et ils gardaient beaucoup de choses de leur fonctionnement de mod.

      Est-ce qu'ils ont vraiment compris qu'ils pouvaient complètement modifier ioUrbanTerror, et qu'ils n'avaient aucune obligation de maintenir une compatibilité avec l'ancien Quake3 ? Est-ce qu'ils ont compris qu'ils pouvaient ne plus être un mod sans avoir besoin de payer une licence Quake 3 (ça coûte combien aujourd'hui ?) ? Pourquoi le SDK Quake3 1.32b serait leur moteur et ioUrbanTerror ne serait pas le leur ? Pourquoi ils avaient besoin d'une licence Quake 3 pour pouvoir développer (ou plutôt distribuer) leurs nouvelles fonctionnalités ?

      Bref, j'ai pas trop compris parce que dans leur annonce ils semblent présenter la chose comme s'ils ne pouvaient pas faire autrement que de faire du propriétaire, alors que c'est faux. Et ils justifient le passage au propriétaire pour pouvoir faire ce qu'on reproche habituellement aux projets libres : un fork. Ça sent un peu le prétexte. C'est leur droit de faire du propriétaire, mais je trouve bizarre de le justifier avec un raisonnement fallacieux !

      UrbanTerror HD n'est pas encore sorti. UrbanTerror 4.2 n'est pas UrbanTerror HD.
      Personnellement j'ai encore la 4.1 d'installé, je ne sais pas trop sous quelle license elle est, le binaire s'appelle toujours ioUrbanTerror, mais il vient avec un fichier nommé QIIIA Game Source (SDK) License.doc.

      Cependant, ils promettent de toujours fournir une version Linux d'UrbanTerror. Ça reste donc un jeu natif Linux, c'est déjà ça, mais il n'est plus garanti de pouvoir le porter sur toutes les distributions Linux, ce qui est bien ta question : Comment installer UrbanTerror sur mon poste Linux.

      Pour WorldOfPadman, j'avoue ne jamais avoir accroché à ce jeu. Je le trouve très abouti, probablement l'un des mods de Quake3 qui a son univers le plus abouti, mais je n'y ai quasiment jamais joué… Comme quoi les goûts et les couleurs… Il faudra que je réessaie !

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: PadMaaaaan ! PadMaaaaan!

        Posté par  (site web personnel) . Évalué à 2.

        Merci pour cette longue réponse.

        • UrbanTerror

        Vu pour la dispo pour linux (du moins, pour systèmes 32 pour la 4.2béta).
        J'avais du me précipiter trop vite lors de l'annonce, seul le binaire Win était là.

        Je reste aussi sur la 4.1.1, et je suis déçu du passage proprio, c'était un bon jeu.
        Un peu comme TrueCombat, c'était bien, donc ça a été abandonnW propriétarisé… Dommage.

        • WorldOfPadMan

        Rejoues-y. Prends-le comme un jeu fun, SU-PAIR-FUN! Et rien d'autre.

        WoP, c'est l'oxymore de Q3A : Se mettre sur la gueule, dans n'importe quel sens. Sans la boucherie.

        Il est impossible de jouer a WoP sérieusement. Mais ça mets l'ambiance dans une LAN.
        (Et c'est un jeu validé par FdF ! (doublecomboretourné, headshot!))

        Proverbe Alien : Sauvez la terre ? Mangez des humains !

  • # à propos de XulRunner

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    On pourrait comparer cette situation avec l'exemple (ouhouh, l'appeau à troll) des projets Mozilla

    Non, je ne pense pas :-)

    Si la plupart des projets d'applis basés sur XulRunner, sont livrées avec leur propre xulrunner, c'est pour d'autres raisons :

    • utilisation d'une version de XulRunner plus récente que celle proposée par le paquet officiel de la distrib. Et si l'appli a besoin d'une version plus récente, c'est bien souvent pour profiter des dernières API de Gecko etc..
    • utilisation d'une version patchée de XulRunner ou buildée différement. Par exemple, BlueGriffon, en plus d'utiliser une version plus récente de XulRunner pour permettre aux utilisateurs d'utiliser les dernières nouveautés HTML5 / CSS3 dans la création de leur page web, contient aussi des patchs, qui ne sont pas encore intégrés en upstream (mais peut-être ce n'est plus le cas aujourd'hui, je crois que Glazou a fait le maximum pour pouvoir utiliser une version non patchée). Autre exemple, l'éditeur Komodo, qui utilise lui aussi XulRunner, a besoin du support python dans les XPCOM. Le flag de build pour cette fonctionnalité n'est pas activée par défaut dans XulRunner. etc..

    Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment. Cela peut convenir pour des petits projets 100% XUL, mais dés que l'on veut faire une appli complexe, on a souvent besoin d'un XulRunner spécifique en version ou patché.

    D'ailleurs, pour ioQuake3, tu as souligné un peu le même souci : divers projets de jeux utilisent une version patchée différente de ioQuake3. L'utilisation d'un libioquake3 commun n'est donc pas possible, non pas parce que les développeurs ils ont la culture windows, mais parce que techniquement ce n'est pas possible. Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.

    • [^] # Re: à propos de XulRunner

      Posté par  . Évalué à 10.

      utilisation d'une version de XulRunner plus récente que celle proposée par le paquet officiel de la distrib. Et si l'appli a besoin d'une version plus récente, c'est bien souvent pour profiter des dernières API de Gecko etc..

      La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne. Sinon, autant packager tout en statique et on évite du même coup les différences de version des autres paquets.

      utilisation d'une version patchée de XulRunner ou buildée différement.

      C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier. Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins. Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.

      Pour moi, le fait que tout le monde utilise sa propre version patchée de xulrunner exhibe juste un problème dans la maintenance de xulrunner lui-même, probablement parce que Mozilla n'est pas intéressé à maintenir celui-ci comme une lib classique (ceci a déjà été vu avec les histoires autours de mozembed par exemple)

      Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment.

      Idem, si Debian package une application, ils se débrouillent pour que les dépendances soient à jour. Cela fonctionne pour tous les autres programmes.

      Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.

      Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.

      Reposer sur des versions patchées des libs n'est jamais une bonne idée.

      • [^] # Re: à propos de XulRunner

        Posté par  (site web personnel) . Évalué à -6.

        La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne.

        Elle peut le faire. Elle peut aussi ne pas le faire. Ah oui, on oubliais le monde parfait des packageurs…

        Reposer sur des versions patchées des libs n'est jamais une bonne idée.

        Tant que tu payes le mec pour remonter le patch upstream et le faire valider… Encore de la théorie. Les gens vivent dans la pratique (même sous Linux).

        • [^] # Re: à propos de XulRunner

          Posté par  (site web personnel) . Évalué à 9.

          Tout le monde sait que c'est pas parfait, mais ça marche pour plusieurs milliers de paquets, et ça ne coincent que pour une minorité.
          Je cherche à comprendre pourquoi ça ne marche pas pour cette minorité (c'est le premier pas pour résoudre le problème), pas à endormir la question sous prétexte que « c'est comme ça c'est pas parfait ».

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: à propos de XulRunner

            Posté par  (site web personnel) . Évalué à -6.

            Tout le monde sait que c'est pas parfait, mais ça marche pour plusieurs milliers de paquets, et ça ne coincent que pour une minorité.

            C'est tellement parfait que tu as des "mods" (ils ne forkent pas tout le dépôt, seulement les logiciels qui plaisent à la personne mais qui sont pas à jour) de dépôts et des "forks" (nouvelles distribs) à tous les coins de rue.
            Applique donc le même esprit d'analyse de ton journal aux dépôts, conclusion?

            En plus, ça n'aide pas à avoir une version à jour pour les serveurs, car le mainteneur du serveur aura du mal à gérer tous les formats de dépots de toutes les distribs (aucun accord entre les auteurs de distro Linux pour une norme commune). Encore de la théorie, rien en pratique, mais on dit "c'est beau ça marche".

            Les dépôts c'est l’idole, ne surtout pas prendre du recul et avoir la moindre critique dessus, cachons les problèmes… C'est triste de perdre son esprit critique quand on parle de Linux ou de ses utilisateurs, C'est triste d'inventer des critiques quand on parle de Windows ou de ses utilisateurs. Toujours trouver un ennemi et passer sous silence les problèmes amis, grand classique humain, qu'on retrouve partout, malheureusement.

        • [^] # Re: à propos de XulRunner

          Posté par  . Évalué à 3.

          Mouai.

          En pratique, je ne vois pas grand monde forker Qt ou Gtk ou livrer leur propre version embarquée avec leur appli dans les systèmes libres, et tous les développeurs qui les utilisent ne sont pas payés.

          C'est effectivement un mode de développement. Il est étonnant que Mozilla, qui la main sur XulRunner mais aussi les "principales" applications qui l'utilisent, n'ait pas de politique pour faire en sorte que ce soit bien une bibliothèque commune et pas un monstre tentaculaire.

          Tu parles de payer le dév pour remonter les patches, je me demande comment quantifier les ressources gaspillées à porter les modifs de chaque appli d'une version à l'autre de XulRunner.

          Ça me donne une piètre idée de la gestion des ressources dans le projet…

          • [^] # Re: à propos de XulRunner

            Posté par  (site web personnel) . Évalué à -2.

            En pratique, je ne vois pas grand monde forker Qt ou Gtk

            Qt et Gtk sont utilisés sous Windows, pas de fork. Donc en utilisant votre logique, ce n'est pas un problème de Windowsien. Merci de m'aider à la démonstration.
            En fait, tu démontres A, et conclue B qui n'a rien à voir.
            Ici, tu peux juste conclure qu'il y a des projets qui savent gérer leur communauté et inciter à patcher, ou dont le projet ne nécissite pas de patch (perso j'utilise Qt et je n'ai pas de version à moi, je suis Linuxien pour toi?). On parle des projets, pas autre chose. Demain, tu en concluras sur les gauchers/droitiers?

            Tu parles de payer le dév pour remonter les patches, je me demande comment quantifier les ressources gaspillées à porter les modifs de chaque appli d'une version à l'autre de XulRunner.
            Ça me donne une piètre idée de la gestion des ressources dans le projet…

            Que tu ne saches pas faire un calcul d’intérêt économique (coût de la remontée upstream avec ses risques de refus contre juste un patch), en ayant un dogme que tu ne remet jamais en question, me donne une piètre idée de la gestion des ressources dans le projet… Google forke pas mal de projets (y compris Linux pour Android), et ils ont une tonne de personnes gérant les ressources humaines, payées pour, mais toi tu sais mieux qu'eux ce qui est rentable. Ou pas (leurs comptes sont au beau fixe). Théorie vs pratique, les faits sont têtus, faudrait interdire les faits. En attendant, les gens font comme ça les arrange.

            • [^] # Re: à propos de XulRunner

              Posté par  . Évalué à 9.

              Qt et Gtk sont utilisés sous Windows, pas de fork. Donc en utilisant votre logique, ce n'est pas un problème de Windowsien. Merci de m'aider à la démonstration.

              En terme de conclusions hâtives tu ne te fais pas prier non plus. Gtk et Qt sont développés principalement sur un environnement Linux et donc profitent de l'idéologie locale du packaging, tandis que les moteurs de jeux et xulrunner sont principalement développés sous Windows et donc souffrent du fait que les développeurs sont moins familiers avec le concept de packager les choses une fois pour toute. Il n'y a strictement rien de plus à en conclure.

              Google forke pas mal de projets (y compris Linux pour Android)

              Et ils sont en train de remonter plein de patches dans le noyau upstream. Le fork est très efficace en terme de ressources sur le court terme, mais très coûteux sur le long terme. Le fait de tout forker pour lancer un nouveau projet est différent du fait de maintenir tout cela sur le long terme.

              De plus, sans vouloir pinailler, comparer google et ses milliers de développeurs avec des projets libres qui luttent pour en trouver quatre…

          • [^] # Re: à propos de XulRunner

            Posté par  (site web personnel, Mastodon) . Évalué à 8.

            Tu parles de payer le dév pour remonter les patches, je me demande comment quantifier les ressources gaspillées à porter les modifs de chaque appli d'une version à l'autre de XulRunner.

            Quand tu suis un projet un minimum et que tu connais bien les sources, je t'assure que porter les modifs d'une version à une autre est souvent bien moins couteux que de proposer en upstream.

            Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça. Corriger ton patch, ça peut être bénéfique bien sûr. Et puis il y a tout un workflow à suivre : proposition du patch, review du patch, vérifier que tout les tests passent, commiter, attendre une nouvelle fois que les tests des machines de build passent etc. Et pour Mozilla, attendre 12 à 18 semaines que ce soit dans une release officielle (et encore, avant le fast release cycle, fallait attendre 1 ou 2 ans). Pour d'autres projets, attendre peut-être des mois et des mois…

            Chez Mozilla, j'ai eu des patchs refusés parce que ça impactait ou était incompatible avec tel ou tel composant externe ou appli mozilla. Le souci, c'est que moi, pour mon appli, j'en avait rien à fiche. Le patch fonctionnait parfaitement pour mon appli, c'était le principal. Parce que la majorité des applis que je développe, c'est pour des clients, ou pour mon employeur (quand j'étais salarié :-)). J'ai des délais pour réaliser une appli. Dans mon exemple, rajouter des heures et des heures pour adapter le patch pour qu'il fonctionne pour tout le monde en upstream n'aurait pas été possible dans le planning du projet. Donc voilà, pas d'intégration upstream pour certains patchs (en tout cas, pas dans un premier temps, et pas dans les délais de réalisation du projet).

            Dans bon nombre d'entreprise, c'est pareil (et j'en vois plein des boites…). les patchs sont proposés en upstream que si le budget le permet, que si on a le temps, ou que si c'est vraiment critique. Ou que si la boite est impliqué à fond dans le développement de la lib, du framework etc..

            Et encore, je ne parle pas des cas où il faut attendre qu'un contributeur en face se bouge pour faire la review ou commiter (quand on n'a pas le "karma" nécessaire dans le projet upstream). Et pour les projets de libs un peu mort…

            Bref, voilà, ça peut être coûteux de contribuer en upstream, dans le cadre d'un projet d'entreprise. Alors oui, on se retrouve avec des applis qui nécessitent des versions personnalisées de bibliothèque, comme c'est souvent le cas avec XulRunner.

            • [^] # Re: à propos de XulRunner

              Posté par  . Évalué à 4.

              Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça.

              … Ou parce que même une fois que tu t'es exécuté, on peut finir par te le refuser. J'ai des témoignages dans le cas précis de Mozilla où des patches pour XulRunner ont au départ été refusés pour des questions de forme (coding style, etc.), puis refusés tout court. De ce que j'ai compris, il s'agissait de patches qui n'avaient pas d'impact « négatif » (au sens de changement lourd dans le comportement de XulRunner). Du coup les personnes en question¹ (qui développent un produit construit par-dessus XulRunner) font leurs propres patches, et ne tentent plus de remonter quoi que ce soit.

              [1] Je ne veux pas parler en leur nom, vu que je n'ai jamais travaillé avec eux, et donc qu'il me manque sans doute des détails…

        • [^] # Re: à propos de XulRunner

          Posté par  . Évalué à 1.

          Elle peut le faire. Elle peut aussi ne pas le faire. Ah oui, on oubliais le monde parfait des packageurs…

          L'idée ici est de laisser aux distros l'option de le faire. Le cas actuel est que les distros ne peuvent pas le faire car les versions de xulrunner ou ioquake3 utilisées sont intrinsèquement incompatibles.

          Pour le cas du "je veux la dernière nightly", il existe toujours l'option générique du tarball lié statiquement, c'est tout à fait orthogonal avec le fait d'avoir une version patchée du moteur de jeu. Skype fournit une version linux compilée statiquement avec Qt, mais je doute fortement que leur version de Qt soit patchée.

          Tant que tu payes le mec pour remonter le patch upstream et le faire valider… Encore de la théorie. Les gens vivent dans la pratique (même sous Linux).

          Sauf qu'en pratique, pousser un patch upstream est plus efficace (moins coûteux) que de le maintenir. Et je ne parle même pas des forks "complets" qui imposent de maintenir la totalité du moteur une fois pour chaque jeu plutôt qu'une fois pour toute, en corrigeant toujours les mêmes bugs et en redéveloppant toujours les mêmes features.

          Cela ne nécessite pas d'être payé. Les gens qui maintiennent Ogre ne sont pas payés il me semble (ça a peut-être changé récemment), il s'agit d'un moteur de jeu sous la forme d'une lib, et tous les gens qui l'utilisent l'utilisent tel quel sans patches. Ils distribuent les jeux sous windows, et souvent il est également possible de les packager sous linux en utilisant le package existant libogre3d (hors jeux proprios évidemment). Ceci prouve que c'est surtout une question de manque d'intérêt et/ou de mésentente ou compétition entre les projets, sur l'idée que "cet effet génial va différencier mon jeu donc j'aurai plus de succès".

          • [^] # Re: à propos de XulRunner

            Posté par  (site web personnel) . Évalué à -2.

            Sauf qu'en pratique, pousser un patch upstream est plus efficace (moins coûteux) que de le maintenir.

            Tu sais mieux qu'eux…

            Ceci prouve que c'est surtout une question de manque d'intérêt

            Comme par exemple que ça leur apporte pas plus d'efficacité.
            CQFD, merci.

            • [^] # Re: à propos de XulRunner

              Posté par  . Évalué à 7.

              Ben, en fait, oui. On travaille avec deux projets libres, l'un en GPL et l'autre sous copyright attribution double licence. Dans l'un des cas on remonte les patches, dans l'autre pas (la politique, tout ça, je passe les détails). On est une très petite boite.

              Donc oui, dans les faits ça me coûte moins cher en temps de remonter les patches une fois que de maintenir ma pile de patches et de les mettre à jour à chaque nouvelle version mineure du projet. Dans le premier cas il m'a fallu quelques jours pour faire accepter le patch, dans l'autre il me faut chaque fois une journée, au mieux, pour adapter les patches. Après genre cinq versions, la première façon de faire est clairement gagnante en terme de temps dépensé.

              Quant à l'intérêt, encore une fois c'est l'intérêt immédiat comparé à un intérêt à plus long terme. Au moment de commencer le jeu il est bien plus facile de forker. Après un an ou deux de galère et de patches divers je me demande si certains ne préféreraient pas avoir moins de code à maintenir et utiliser un moteur commun. Moins de code à maintenir, c'est aussi plus de temps à investir dans d'autres aspects du développement, comme de nouvelles fonctionnalités, un meilleur gameplay ou de nouveaux niveaux. Cependant, passer d'un fork à l'utilisation d'un moteur commun ne se fait pas en une nuit, et donc, encore une fois l'efficacité à court terme est de conserver son fork.

      • [^] # Re: à propos de XulRunner

        Posté par  (site web personnel) . Évalué à 3.

        Pendant ce temps, dans le monde Java ou Python, on a résolu ces problèmes de dépendances avec des outils comme Maven ou virtualenv.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: à propos de XulRunner

          Posté par  . Évalué à 2.

          (Note : je suis un inconditionnel de Maven, mais…)

          Résolu les problèmes de dépendances ? C'est encore loin.
          Je ne sais pas pour virtualenv, mais pour maven, on peut certes dire que ça les simplifie grandement, mais pas que ça les résout.

          Les dépendances sont toujours agglomérées dans un classpath unique. Il faut être extrêmement prudent quand on a une même dépendance tirée dans des versions différentes, et choisir celle qui marche… quand c'est possible.

          Un exemple : slf4j autour de la version 1.6, avec des compatibilités ascendantes non respectées, si on a une dépendance transitive avant la charnière et une autre après, on est pas sûr de pouvoir faire fonctionner le résultat. J'ai vu d'autres problèmes du même type avec cglib et autres bibliothèques qui sont souvent tirées par plusieurs dépendances.

      • [^] # Re: à propos de XulRunner

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne

        dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte, pour avoir le paquet officiel de la dernière version de XulRunner. Et encore, quand une debian sort, bon nombre de paquet ne contiennent pas les dernières releases des libs.

        "Bonjour monsieur le client, alors, je vous ai développé votre appli avec XulRunner comme vous le souhaitez, mais il va vous falloir attendre 3 ans ou plus que la prochaine debian stable sorte pour en profiter, parce que la version actuelle de XulRunner est bien trop vieille pour les besoins de l'application."

        C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier.

        Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.

        Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.

        Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins.

        Tout ne peut pas se faire par des plugins. Par exemple, à l'époque où je développais mon éditeur XML wysywyg, j'avais plein de modification dans le coeur du code de l'éditeur de gecko. Impossible d'avoir l'éditeur sous forme de plugin, ça fait parti intégralement du coeur de gecko pour plein de raisons (liés très intimement au moteur de rendu par exemple). Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.

        Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.

        Tout les patchs customs ne sont pas forcément utile en upstream car trop spécifiques (c'était le cas de mon éditeur). Donc ça ne sert à rien d'attendre une release de XulRunner.

        si Debian package une application, ils se débrouillent pour que les dépendances soient à jour.

        Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)

        Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.

        Oui genre, on peut mettre des hooks partout et puis surtout, en upstream, ils vont accepter ta tonne de patchs insérant des hooks partout… (et je passe sur le coté performance quand il y a des tonnes de hooks)

        XulRunner a souvent été utilisé pour des applis innovantes, qui avaient besoin de choses en plus, ou des comportements différents dans le moteur de rendu ou dans des composants.

        • [^] # Re: à propos de XulRunner

          Posté par  . Évalué à 3.

          dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte pour avoir le paquet officiel de la dernière version de XulRunner.

          Et pourquoi le ferait-il? En quoi utiliser une version forkée de xulrunner change-t-il quelque chose à cela? Ou bien le problème est-il pour l'éditeur de logiciel d'attendre que Mozilla ne release une nouvelle version de xulrunner ? Côté éditeur, on peut soit packager une nouvelle version de xulrunner soi-même, soit compiler son paquet statiquement. On fait des trucs similaires dans ma boite. Si au contraire c'est Debian qui veut la nouvelle version de Thunderbird, elle se débrouillera pour fournir un package du dernier xulrunner.

          Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.
          Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.

          Comme Qt, qui fournit QtQuick, Webkit, un client HTTP, un environnement de scripting javascript et plein d'autres trucs. Qt n'est pas une lib classique, c'est une plateforme, un framework embarquable. Est-ce pour autant que tout le monde forke et patche ? Non. Il s'agit juste de faire en sorte que la plateforme fournisse tout ce qui est nécessaire, et d'ajouter ce qui manque pour avoir une plateforme satisfaisante pour tous les usages, et réduire d'autant les coûts de maintenance des différentes applications.

          Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.

          Je sais que Mozilla assume pleinement le fait que xulrunner est avant tout la plateforme de Firefox et refuse d'implémenter des choses qui ne sont pas dans l'intérêt immédiat de Firefox. Il n'y a pas de problème intrinsèque avec cela, il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.

          Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.

          Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ? Peut-être est-ce un problème de design ou de modularité du moteur gecko, ou de refus d'ajouter des fonctionnalités qui ne sont pas directement nécessaires à Firefox (bien que avec les nouveaux webdev tools…) ? D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu. Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.

          Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)

          Non, c'est un raccourci malsain, car comme dit plus haut, le fait de pouvoir le faire n'implique pas qu'on ne peut pas faire autrement. On peut distribuer une appli compilée statiquement, et de toute façon le problème est le même pour les dépendances déjà présentes dans la distro (cairo, gtk+, libx* et toutes les autres). Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.

          • [^] # Re: à propos de XulRunner

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Est-ce pour autant que tout le monde forke et patche ? Non.

            Tu es allé dans toutes les boites qui font du Qt ? et sur des projets internes ? Je suis sûr que non, donc tu ne peux pas affirmer cela.

            Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.

            Le choix d'un framework ne se fait pas seulement sur la facilité de patcher en upstream etc.. Le choix se fait aussi sur les technologies, sur ce que cela offre pour répondre à des besoins. Par exemple, développer (ou intégrer dans l'application) un navigateur web basique avec xulrunner, se fait en 5 minutes, et sans environnement de compilation ou autre. Avec webkit, c'est quand même moins évident, faut quand même un minimum d'heures.

            il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.

            Je ne sais pas où tu as vu où Mozilla, ou quiconque, y compris moi, promeut encore XulRunner. J'ai arrêté de promouvoir XulRunner le jour où Mozilla avait annoncé qu'ils n'en ferait pas un produit. Même si cela ne m'empêche pas de l'utiliser pour certains projets, ce n'est pas quelque chose que je propose absolument à mes clients ou que je le cri sur tout les toits.

            Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ?

            C'est une blague ? Tu prend les versions stables de toutes les applis et navigateurs utilisant webkit, pas une n'utilise la même version de webkit. D'ailleurs les développeurs web s'en plaignent. Surtout qu'avec Webkit, tu as plusieurs backend possible pour telle ou telle partie, ce qui fait que tu n'as pas un webkit identique.

            D'ailleurs, si tu regardes dans debian, libqt4-webkit n'utilise pas par exemple le paquet libwebkit-1.0-2. Tu as donc au moins deux versions de webkit dans debian.

            D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu.

            XulRunner, ce n'est pas seulement un moteur de rendu.. M'enfin, je n'ai plus trop le temps d'expliquer ce qu'est XulRunner, Gecko, l'ecosystème Mozilla etc…

            On peut distribuer une appli compilée statiquement

            Oui, et bien ? Je ne comprend pas. C'est ce que je dis non ? Des projets fournissent leur propre XulRunner (d'ailleurs le binaire xulrunner est souvent renommé). C'est pareil que de fournir une appli avec des libs compilées statiquements, donc non partagées avec d'autres applis.

            (ne sommes nous pas en train de nous prendre la tête alors qu'on est d'accord ?)

            • [^] # Re: à propos de XulRunner

              Posté par  (site web personnel) . Évalué à -1. Dernière modification le 22 août 2012 à 16:45.

              D'ailleurs, si tu regardes dans debian, libqt4-webkit n'utilise pas par exemple le paquet libwebkit-1.0-2. Tu as donc au moins deux versions de webkit dans debian.

              Oh le beau "fail" par rapport à toute la théorie "les linuxiens ils font les choses plus mieux bien que les Windowsien", surtout vu les louanges faits sur Qt et le "ça respecte les principes". On a une belle démo, factuelle, que ce n'est pas l'OS préféré des développeurs qui est l'élément différenciateur… N'en déplaise à ceux qui veulent toujours accuser l'autre de tous les problèmes, et qui, je sais bien, continueront à utiliser l'autre comme bouc émissaire des problèmes.

              Merci pour rappeler les faits. D'un côté la théorie, de l'autre la réalité.

            • [^] # Re: à propos de XulRunner

              Posté par  . Évalué à 6.

              D'ailleurs, si tu regardes dans debian, libqt4-webkit n'utilise pas par exemple le paquet libwebkit-1.0-2. Tu as donc au moins deux versions de webkit dans debian.

              D'un autre coté libwebkit c'est le port GTK de webkit. Ça me semble assez normal que ce ne soit pas utilisé par Qt.

              • [^] # Re: à propos de XulRunner

                Posté par  (site web personnel) . Évalué à 1.

                La question n'est pas la.
                La question est de savoir si il y a deux version du code Webkit. Quel que soit l'endroit où c'est packagé. Et à 20 MB le package, il faut espérer que ce package n'est pas qu'un binding GTK, mais contient Webkit. Et donc, on a bien deux webkit dans la nature Debianiesque, avec en plus des "poids lourds" libristes, ce qui casse complet la théorie initiale.

                • [^] # Re: à propos de XulRunner

                  Posté par  (site web personnel) . Évalué à 2.

                  Euh non ça ne casse rien, dans ce cas là webkit rejoint gecko dans la liste des exceptions, ça ne change rien à la tendance générale ni la volonté habituelle.

                  ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: à propos de XulRunner

                    Posté par  (site web personnel) . Évalué à -1. Dernière modification le 22 août 2012 à 19:54.

                    On prend deux cas par ci, ça en fait une généralité.
                    On prend deux cas par la, ça en fait des exceptions.

                    Vachement objectif. D'ailleurs, rigolo, Qt était présenté comme un argument "mentalité Linux", mais maintenant machine arrière toute quand on regarde un peu ce qui est dit. Perte de crédibilité à fond.

        • [^] # Re: à propos de XulRunner

          Posté par  . Évalué à 0. Dernière modification le 22 août 2012 à 11:16.

          dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte, pour avoir le paquet officiel de la dernière version de XulRunner. Et encore, quand une debian sort, bon nombre de paquet ne contiennent pas les dernières releases des libs.

          Pourtant il peut faire son propre dépôt. Tout est documenté.

          Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.

          Pourquoi donc développer avec XulRunner si elle n'est pas une bibliothèque complète et ne correspond qu'à quelques besoins spécifiques ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: à propos de XulRunner

          Posté par  . Évalué à 1.

          XulRunner a souvent été utilisé pour des applis innovantes, qui avaient besoin de choses en plus, ou des comportements différents dans le moteur de rendu ou dans des composants.

          Lesquelles ? Parce qu'à part Firefox et un peu Thunderbird, je ne vois pas beaucoup de trucs innovants basés sur Xul…

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Tu y vas un peu vite

    Posté par  (site web personnel) . Évalué à 4.

    Alors, je vais tenter un avis et prendre beaucoup de risque… mais ça semble venir du fait que la majorité des dévelopeurs sont sous windows et ne connaissent pas la joie d'un dépôt.

    Je ne vois pas le rapport : ce n'est pas parce qu'on n'a pas la notion de dépôt pour la distribution qu'on n'a pals a notion de dépôt pour le source. C'est complètement séparé.
    Pour troller, c'est aussi sans compter sur l'horreur de l'unique version sur un dépôt, qui n'est pas assez à jour mais que le mainteneur ne veut pas mettre à jour sinon ça casse un autre logiciel dont on a rien à faire.

    Revenons au problème : le code source. Et la, si tu regarde bien, ça n'a rien à voir avec la distribution ce code source. Mais à l'acceptation de travailler ensemble :
    - Côté upstream, il faut une personne qui passe du temps à tester les patchs et les accepter
    - Côté downstream, il faut une personne qui passe du temps à corriger des bugs qu'il n'a pas (car il n’utilise pas le code comme ci comme ça)

    Aucune des deux personne ne gagne quelque chose à court terme. Faut imaginer le long terme, et c'est dur à quantifier et à faire, surtout en gratos. C'est tout.

    Bref : ne pas taper sur Windows quand ça n'a rien à voir, c'est juste un joli bouc émissaire.

    • [^] # Re: Tu y vas un peu vite

      Posté par  (site web personnel) . Évalué à 4.

      J'aurai du sous-titrer « appeau à Zenitram » ;-)

      Il y a quand même une furieuse tendance à forker dans tous les sens, et cette tendance n'est pas uniuqement due au fait que le logiciel soit libre. Le fait que le logiciel soit libre rend le fork possible, mais ne rend pas le fork nécessaire.
      Autre exemple : la multitude de forks de radiant qui ont existés… gtkradiant, qeradiant, zeroradiant, netradiant, xrealradiant, darkradiant…
      Chaque jeu proposant un fork du fork livré avec un pack de ressources.

      Si on peut le justifier pour un moteur de jeu, cela devient tout de suite beaucoup plus difficile concernant le modeleur ! Pourquoi tant de forks dans ces projets principalement développés sous Windows ? Ce qui est certain, c'est que sous Windows personne ne peut diffuser un paquet de ressources qui dépend de netradiant ! Personne ne peut diffuser des ressources seules en sachant que cela va automatiquement installer le modeleur avec. Il faut tout fournir : les ressources, le modeleur, gtk… Et hop voilà un fork !

      Alors ce n'est peut-être pas spécifique au développement sous Windows, en tout cas cela semble spécifique au développement de jeu vidéo, essentiellement sous Windows.

      Voire plus haut mon commentaire sur la direction que prend UrbanTerror, qui laisse à penser que pour certains, faire un vrai jeu c'est faire un jeu proprio, tout comme pour certains, on n'est pas un artiste tant qu'on n'est pas sociétaire SACEM.

      On ressent assez fortement certaines manières de travailler… Par exemple si les codeurs du moteurs utilisent volontiers un gestionnaire de version comme GIT ou SVN pour travailler… Le mappeur lui a tendance à faire tout tout seul dans son coin et à publier des résultats finis. Je n'ai pas encore vu parmi ces jeux quelqu'un proposer un dépôt pour une carte, et l'ouvrir à la collaboration. D'ailleurs, certains publient leur map sous license CC-By-SA mais fournissent les sources de leurs maps à quelques initiés sous NDA et se plaignent des autres qui la décompilent.

      Par exemple, il y a un gars assez réputé dans l'univers du mapping nommé Ingar, il a sorti des cartes très abouties pour Tremulous, c'est lui qui fournit le package netradiant pour Tremulous sous linux. C'est un mappeur linuxien impliqué dans plusieurs projets libre… Et pourtant quand je lis ses pages de maps je suis étonné, par exemple sur la page de Vega, je cite :

      I also received the kind permission from KOsAD to use assets from his Tremulous map Metro, from gareth, to use assets from his Tremulous map Sector B17, and from Jestr, to use his Sedna texture.

      On est loin de la manière de procéder dans le libre, il est obligé de demander des autorisations spécifiques pour réutiliser du travail, je ne pense pas que cette méthode de travail vienne de son expérience du libre, mais des méthodes de travail du monde du mapping Q3 qui tourne quasi exclusivement sous windows, hérité de l'historique des mods proprios de Quake3 sous Windows.

      Windows n'est pas forcément la cause directe, mais c'est le système le plus répandu dans le monde du jeu vidéo propriétaire et dans le monde du jeu vidéo libre, et les développeurs de jeux vidéos libres sous Windows semblent suivre les méthodes des développeurs de jeux vidéos propriétaires sous Windows. Windows n'est peut-être pas la cause, mais le lieu où ces méthodes de travail collusionnent.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Tu y vas un peu vite

        Posté par  (site web personnel) . Évalué à -6.

        et les développeurs de jeux vidéos libres sous Windows semblent suivre les méthodes des développeurs de jeux vidéos propriétaires sous Windows.

        C'est sûr, c'est tellement classique chez les développeurs de jeux vidéos propriétaires sous Windows de forker… Hum, sans commentaire.
        Désolé de réagir quand on prend Windows pour l'arabe du coin, dès qu'il y a un soucis c'est forcément sa faute. C'est pas faute d'avoir argumenté sur pourquoi ça ne peut pas être ça… Laurent J, que je ne soupçonnerai pas d'être anti-Linux, dit à peu près la même chose : ça n'a rien à voir, autant aux jeux vidéos (il y a des forks partout) qu'à l'OS (Blue Griffon, c'est un truc de Windowsien? Il va y avoir un qui va s'étrangler). Autre exemple, cette plainte du fork est aussi chez Google (Chrome qui patche toutes les libs, Android).

        Encore une fois, le mode de développement n'a rien à voir avec le mode de distribution. Je t'ai donné une raison du pourquoi, mais tu l'as ignorée tranquillement plutôt que contre argumenter dessus.

        Alors ce n'est peut-être pas spécifique au développement sous Windows, en tout cas cela semble spécifique au développement de jeu vidéo, essentiellement sous Windows.

        Alors ce n'est peut-être pas spécifique au arabes, en tout cas cela semble spécifique aux voleurs, essentiellement des arabes. Tu te rends compte de la "logique" que tu utilises?

        Un peu d'objectivité sans attaques gratuites un jour? Devrons-nous inventer un mot pour le racisme contre les OS? Ca craint…

        • [^] # Re: Tu y vas un peu vite

          Posté par  (site web personnel) . Évalué à 8. Dernière modification le 21 août 2012 à 22:01.

          Un peu d'objectivité sans attaques gratuites un jour? Devrons-nous inventer un mot pour le racisme contre les OS? Ca craint…

          Ce que tu n'as pas compris, c'est que je ne compare pas Linux et Windows, mais les gens qui développent avec un dépôrt, et l'univers des gens qui développent sans savoir ce qu'est un dépot, et bien c'est peut-être pas la faute à Windows, mais la majorité de ces gens sont sous Windows. Toi tu as lu "Windows" et hop ça t'as piqué.

          Autre exemple, cette plainte du fork est aussi chez Google (Chrome qui patche toutes les libs, Android).

          Oui, complètement, et cette plainte je l'a entendue plusieurs fois dans des journaux ici.

          Blue Griffon, c'est un truc de Windowsien? Il va y avoir un qui va s'étrangler

          Je n'avais pas osé dire que BlueGriffon était un truc de Windowsien, seulement la manière d'intégrer XulRunner, je n'ai cité que BlueGriffon parce que c'est celui qui m'est venu à l'esprit quand j'ai cherché un projet basé sur XulRunner qui n'était pas un projet de la MoFo.
          La prochaine fois je citerai Celtx, comme ça je serai tranquille ?

          J'avais voulu citer BlueGriffon pour donner un exemple de logiciel qui subit la manière d'intégrer XulRunner (parce que je le suppose plus connu que Celtx), oui je dis bien subit, parce que la plupart des logiciels qui intègrent une version spécifique de XulRunner, c'est pas par choix, c'est qu'ils ne peuvent pas faire autrement. Et ça tu ne l'as pas saisi, donc tu n'as pas saisi mon exemple ni la raison de mon exemple et donc tu n'as pas aisi mon intention. Pourquoi les projets forkent tous ioQuake3 ? Pourquoi il n'y a pas de libIoQuake3 ? J'essaie de répondre à ces questions, pas de poignarder du Windows. Mais toi tu as vu Windows et t'as pas cherché à comprendre. Si je parles de Windows, ce n'est pas ma faute, c'est parce que la majorité des développeurs des projets que j'ai cité sont sous Windows.

          Par contre c'est vraiment drôle parce que je n'avais pas fait exprès, mais BlueGriffon est l'exact exemple d'un comportement Windowsien : sous Linux l'installeur place l'icône dans Menu → Nom de la boîte → Nom du logiciel, avec à coté une entrée Menu → Nom de la Boîte → Désinstaller le logiciel.
          Je crois que tous les lecteurs de DLFP ayant eu affaire à un Windows devineront d'où vient ce comportement. Personnellement, c'est la première fois que je vois un logiciel se comporter de cette manière là sous Linux ! Ensuite BlueGriffon est un logiciel en version démo, il est libre certes, mais les versions téléchargeables sont volontairement amputées et il faut acheter des extensions pour qu'il soit complet. C'est un droit de l'auteur, mais c'est le seul logiciel libre de bureau que je connaisse qui fasse cela, et on ne peut pas franchement dire que cela fait partie des méthodes de travail habituelles sous Linux. À coté Firefox est un exemple, et il y a pleins de logiciels proprios sous Linux qui font mieux que BlueGriffon question intégration et « bonne manières ».

          Bref, bon, là tu te ridiculises. BlueGriffon est l'exemple type du logiciel qui reporte les manières Windowsiennes sous Linux. Je n'avais pas cité BlueGriffon pour dire cela, plutôt pour dire qu'il subissait le comportemet de la MoFo avec XulRunner, bref, tout l'inverse, mais puisque tu le demandes, désolé, mais je peux pas laisser passer une aussi grosse bêtise : BlueGriffon est une horreur d'intégration sous Linux, et c'est l'exemple type de pratiques Windowsiennes rapportées sous Linux. C'est factuel.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Tu y vas un peu vite

            Posté par  . Évalué à 2.

            J'avais voulu citer BlueGriffon pour donner un exemple de logiciel qui subit la manière d'intégrer XulRunner (parce que je le suppose plus connu que Celtx)

            Tu aurais pu citer aussi SongBird, qui comme par hasard n'est disponible que sous Windows et Mac. Ce sont les utilisateurs qui ont dû le forker pour le porter pour Linux…

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Tu y vas un peu vite

          Posté par  (site web personnel) . Évalué à 2.

          C'est sûr, c'est tellement classique chez les développeurs de jeux vidéos propriétaires sous Windows de forker…

          C'est dans les habitudes (si ce n'est par nécessité) de fournir une copie de toutes les bibliothèques tierces à Windows et au développeur de Jeu.
          Ce n'est pas encore un fork, mais c'est la première étape pour un fork, le fork devient alors très très facile.

          Et puis c'est pas comme si les développeurs utilisateurs de bibliothèques propriétaires diffusaient ouvertement les modifications qu'ils apportent à ces bibliothèques pour les adapter à leurs projets (bibliothèques pour lesquelles ils n'ont qu'un droit pour leur pomme) !

          ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Tu y vas un peu vite

          Posté par  . Évalué à -3. Dernière modification le 23 août 2012 à 14:55.

          Alors ce n'est peut-être pas spécifique au arabes, en tout cas cela semble spécifique aux voleurs, essentiellement des arabes. Tu te rends compte de la "logique" que tu utilises?

          Un peu d'objectivité sans attaques gratuites un jour? Devrons-nous inventer un mot pour le racisme contre les OS? Ca craint…

          Tu te rends compte de la stupidité de tes propos.
          Tes phobies, aliénations et trouble racial on s'en tape.

          En tout objectivité je hais les fauteurs de trouble de ton éspèce.

          Prend ton pin's et astalavista.

          CC-BY-NC-SA

  • # dépôts

    Posté par  . Évalué à 3. Dernière modification le 21 août 2012 à 19:27.

    Alors, je vais tenter un avis et prendre beaucoup de risque… mais ça semble venir du fait que la majorité des dévelopeurs sont sous windows et ne connaissent pas la joie d'un dépôt.

    Les dépôts ne sont pas la solution, mais font aussi parti du problème. Pour un jeu en ligne, tu as envie que tes joueurs utilisent la dernière version, compatible avec les serveurs. Or il est possible qu'une distribution fournisse un jeu qui sort entre temps une nouvelle version incompatible avec l'ancienne.

    Pour une distro en roulé boulé, ça ne pose pas de souci, mais pour une distro à la glace la version dans les dépôts devient inutile.

    • [^] # Re: dépôts

      Posté par  (site web personnel) . Évalué à 5.

      C'est le défaut des dépôts, mais il est possible de combiner l'avantage du dépôt de proposer une version standard et commune d'un paquet, avec l'avantage de mise à jour récente avec un dépôt fait pour cela. Par exemple Debian propose un dépôt -updates (anciennement -volatile) pour les mises à jours qui changent vite (signatures de virus clamav par exemple), un dépôt -bakport pour les applications qui se doivent d'être récentes (libreoffice, firefox).

      Le dépot PlayDeb (même s'il n'est pas un dépôt Ubuntu officiel) fait très bien ce boulot : il propose même la beta d'Unvanquished, et est le distributeur officiel de Warsow pour Ubuntu !

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: dépôts

      Posté par  . Évalué à 3.

      Pour toute application "multi-utilisateurs", telles que jeux en ligne mais on peut en imaginer d'autres (suites bureautiques collaboratives, etc.), il est important que tout le monde utilise la même version du logiciel.

      Et là, franchement, je ne vois pas où est l'inconvénient du dépôt, bien au contraire!
      Sans dépôt: tous les utilisateurs doivent se mettre d'accord entre eux sur la version à utiliser. Certains ne jurent que par la version stable, d'autres veulent utiliser la dernière nightbuild et changent donc tous les jours.

      Avec dépôt, pourvu qu'il soit vraiment centralisé:
      On n'a pas toujours le choix de la version, mais au moins on a tous la même!

      Il "suffirait" (yaka, faukon hein!) que les serveurs soient associés aux dépôts et l'indiquent.

      Et non, pour un jeu en ligne, je ne veux pas que les joueurs utilisent la dernière version bêta qui en fait est une alpha et pète de partout.
      Je veux qu'ils utilisent tous la même version qui marche.

      À la limite (si c'était moi, mais ça ne l'est pas, soyons clairs), je proposerais peut-être deux versions: la dernière stable, et la version de développement, pour encourager les tests, sans aucune garantie que le serveur ne plante pas toutes les heures ou quand on éternue.

      Je ne comprends pas que d'un côté on râle parce que "Linux, c'est le bordel, y'a trop de distros avec des politiques différentes, un format de paquets qui change, etc.", et d'un autre, on dise que "mais c'est super, tous ces patches dont on ne sait plus s'ils sont compatibles entre eux!! Installons-les tous le plus vite possible, et demandons aux serveurs de suivre notre combinaison improbable et non-uniforme de patches qu'on change toutes les semaines!"

      La raison du problème pour Tremuluous, c'est qu'il n'y a plus de version stable.

      Comme pour le journal sur le pourquoi du comment du pas libre dans les jeux, je vais demander:

      Pourquoi un jeu aussi populaire que Battle for Wesnoth n'a aucun fork, n'a pas de problèmes de serveurs qui n'ont pas le dernier patch à la mode, etc?

      • [^] # Re: dépôts

        Posté par  (site web personnel) . Évalué à 2.

        Pour toute application "multi-utilisateurs", telles que jeux en ligne […] il est important que tout le monde utilise la même version du logiciel.
        Avec dépôt, pourvu qu'il soit vraiment centralisé:
        On n'a pas toujours le choix de la version, mais au moins on a tous la même!
        Il "suffirait" (yaka, faukon hein!) que les serveurs soient associés aux dépôts et l'indiquent.

        Une question qui me viens à l'esprit, mais les plate formes comme Steam ne rendent pas déjà ce genre de service sous Windows ? (c'est une vraie question, je n'ai jamais utilisé Steam).

        Pour continuer sur le débat du dépôt, FlightGear 2.8 est sorti il y a quelques jours à peine, et PlayDeb propose déjà la version 2.8 !

        La raison du problème pour Tremuluous, c'est qu'il n'y a plus de version stable.

        C'est une bonne conclusion pour mon journal. :)

        Pourquoi un jeu aussi populaire que Battle for Wesnoth n'a aucun fork, n'a pas de problèmes de serveurs qui n'ont pas le dernier patch à la mode, etc?

        Parce que la gestion est meilleure que celle de Tremulous ? :)
        Parce que la meilleure manière de ne pas avoir de fork est d'être un projet vivant, stable et bien géré ?

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: dépôts

          Posté par  . Évalué à 2.

          Avec dépôt, pourvu qu'il soit vraiment centralisé:

          Une question qui me viens à l'esprit, mais les plate formes comme Steam ne rendent pas déjà ce genre de service sous Windows ? (c'est une vraie question, je n'ai jamais utilisé Steam).

          C'est marrant je me suis fait la même réflexion en rentrant. Une faille dans son raisonnement était qu'il n'existait pas actuellement de dépôt vraiment centralisé mais si: Steam et DJL par exemple.

          Par contre pour Steam on a pas le choix de la version que l'on veut utiliser, il met automatiquement à jour à la dernière version si ma mémoire ne défaille pas trop.

          Et DJL, semble abandonné :(

        • [^] # Re: dépôts

          Posté par  (site web personnel) . Évalué à 2.

          Une question qui me viens à l'esprit, mais les plate formes comme Steam ne rendent pas déjà ce genre de service sous Windows ? (c'est une vraie question, je n'ai jamais utilisé Steam).

          À peu près. Par exemple il t'installe .NET à la bonne version la première fois que tu installes un jeu qui la requiert.

    • [^] # Re: dépôts

      Posté par  (site web personnel) . Évalué à 2.

      Pour la compatibilité, il est parfois possible de s'en sortir en utilisant un protocole qui gère le versioning.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: dépôts

      Posté par  . Évalué à 3.

      pour une distro à la glace la version dans les dépôts devient inutile

      Même pas, il y a les backports pour ça.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # gestionnaire de paquets

    Posté par  . Évalué à 2.

    On pourrait avancer (ouhouh, je prends des risques) que l'absence de gestionnaire de paquet sous Windows

    Y'a bien le windows store pourtant.

    • [^] # Re: gestionnaire de paquets

      Posté par  (site web personnel) . Évalué à 4.

      Est-ce qu'il permet de faire dépendre les paquets les uns des autres ? (c'est une vraie question, je ne sais pas) Si ce n'est pas possible, alors le raisonnement est toujours valable : devoir toujours livrer son programme avec une n-ième version des bibliothèques utilisées, ce qui est déjà le début d'un fork.

      Est-ce que le Windows store a déjà commencé à changer les habitudes de développement ?

      ce commentaire est sous licence cc by 4 et précédentes

  • # nimage

    Posté par  . Évalué à -6.

    Il manque une nimage a ton journal.

    • [^] # Re: nimage

      Posté par  (site web personnel) . Évalué à 4.

      J'ai hésité à jouer au jeu de la nimage et à proposer celle-ci : nimage
      Mais je ne saisis pas vraiment ta nimage (il y a des gens pour fantasmer dessus ?) !

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: nimage

        Posté par  (site web personnel) . Évalué à 2.

        nimage (il y a des gens pour fantasmer dessus ?) !

        C'est dans la définition de devoir fantasmer sur une nimage? Tu fantasmes sur les nimages de fork_bomb? euh… Pas moi en tous cas.

        • [^] # Re: nimage

          Posté par  (site web personnel) . Évalué à 2.

          C'était pour faire référence aux débats précédents, j'aurai pu dire aussi « Ce genre d'image est-elle une récompense pour quelqu'un ? » en référence à ce commentaire.

          J'ai hésité entre le cliché « c'est pour des machos frustrés fantasmant derrière leur écran » et « c'est une carotte pour les liseurs de nourjals », j'ai choisi le premier /o\.

          ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: nimage

        Posté par  . Évalué à 5.

        Puisque selon certain le but des nimages est de faire réagir, allons-y gaiement :)

        /rattrapage

        En fait je me suis gourré de nimage je voulais mettre celle-là, rapport aux FPSs tout ça.

  • # Données forkées

    Posté par  (site web personnel) . Évalué à 3.

    Les données ne sont quasiment jamais forkées, parce que justement elles constituent l'identité du jeu beaucoup plus que le moteur, c'est donc beaucoup plus risqué. Ce sont les moteurs qui forkent.

    Ben, Unvanquished pour moi c'est en majeure partie de nouvelles données et des tweaks pour équilibrer le jeu, j'ai pas vu de nouvelles features.

    Aussi, tu as oublié d'expliquer ce qu'est Daemon, on le devine un peu du contexte, mais c'est pas explicitement dit.

    • [^] # Re: Données forkées

      Posté par  (site web personnel) . Évalué à 2.

      Unvanquished pour moi c'est en majeure partie de nouvelles données et des tweaks pour équilibrer le jeu,

      Bonjour,

      le jeu te semblait déséquilibré?

      J'ai remarqué que les nouveaux joueurs choisissaient de jouer les "humains", mais toujours en solo…

      Pourtant, et c'est bien dit dans le journal, Tremulous se joue en équipe, et nécessite une certaine forme d'organisation et de discipline, surtout pour ne pas nourrir inutilement l'autre camp.

      A jouer n'importe comment, c'est certain qu'on peut lui trouver des défauts, et c'est justement pour ça que des équipes préfèrent jouer entres-elles, pour avoir une qualité de jeu, avec des sensations.

      Bonne journée
      G

      PS : J'ai beaucoup joué sur les serveurs Bricosoft…

      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: Données forkées

        Posté par  (site web personnel) . Évalué à 3.

        Non, le jeu m'a jamais paru particulièrement déséquilibré, je joues depuis un moment mais trop rarement, en fait je ne trouve Tremulous drôle qu'en LAN, sur internet avec des inconnus l'esprit d'équipe n'est pas là.
        J'ai toujours préféré jouer Alien… (sauf là sur unvanquished parce qu'il ya plus de nouveaux modèles à voir coté humain )

        Je disais "des tweaks pour équilibrer le jeu" parce que c'est ce que j'ai constaté : les dretchs sont plus gros, les tyrans ont 50pvs de moins, j'ai l'impression que certains trucs ont bougés entre le 2e et le 3e stage (si ma mémoire ne me fait pas défaut dans Tremulous l'advanced dragoon arrivait stage 3 et non stage 2), …

        Sur mon expérience personnelle, au début quand tout le monde était débutant les aliens avait clairement le dessus, après un peu d'entraînement c'est plutôt les humains qui s'en sortaient mieux.

    • [^] # Re: Données forkées

      Posté par  (site web personnel) . Évalué à 4.

      Aussi, tu as oublié d'expliquer ce qu'est Daemon, on le devine un peu du contexte, mais c'est pas explicitement dit.

      Ah oui en effet !
      Donc, comme on le devine, dans le projet Unvanquished fork de TremZ (le jeu complet), Daemon est le fork d'OpenWolf (le moteur).

      Ben, Unvanquished pour moi c'est en majeure partie de nouvelles données et des tweaks pour équilibrer le jeu, j'ai pas vu de nouvelles features.

      Les quelques tweaks qui sont là ressemblent furieusement à ceux qui ont été expérimentés par tous les forks précédents, donc on peut dire que le risque n'est pas grand, une partie du travail avait déjà été éprouvée.
      Pour les données, ils n'ont pour le moment remplacé que des modèles et des textures (ce qui ne change pas encore le gameplay), et ont commencé à intégrer des maps (ce qui peut changer le gameplay, mais c'est propre à la map, pas au jeu). Ils n'ont pas touché aux différentes classes d'Alien, ni aux types d'armes, ni aux différents objets constructibles et à leur rôle stratégique.
      Question jeu, je n'ai senti encore aucune différence, certains détails graphiques ont changé, mais ça ne modifie rien à l'expérience de jeu ni à l'ambiance. Je trouve qu'ils font ça d'une manière assez juste, sans prendre de trop gros risque.

      On peut dire que la migration de tremulous depuis le moteur originel vers Daemon est déjà un succès, maintenant il peuvent s'attaquer au reste par petite touche. Et puis comme Tremulous 1.1.0 est déjà vieux de six ans, cela permet de poser un regard plus neuf sur Unvanquished, beaucoup de petites variations n'ont plus de risque de choquer.

      Aussi, je n'ai peut-être pas été très clair, mais dans mon commentaire « _Les données ne sont quasiment jamais forkées […] Ce sont les moteurs qui forkent._ », il faut comprendre que ces données contiennent une grosse part de la logique du jeu, et pas seulement les textures ou les sons. Dans les jeux basé sur un moteur idTech, on peut voir un peu le moteur comme un interpréteur (c'est une analogie), Ce qui détermine qu'il y ai une équipe d'humain et d'alien, que les aliens puissent muter mais pas les humains, que les humains puissent acheter et vendre des armes, qu'il faille un réacteur pour construire une nouvelle structure humaine etc. tout ça n'est pas dans le moteur Daemon/idTech3, mais le moteur Daemon/idTech3 propose des fonctions qui permettent d'implémenter cette logique.
      Les données, dans ce type de jeu, c'est plus qu'un thème.

      On pourrait faire une analogie avec navigateur exécutant un webmail : ils ont remplacé chrome par firefox (interpréteur js, xml, css = le moteur), ils ont commencé à faire varier la css et les images, mais ils n'ont pas touché au javascript ni au concept du webmail. C'est toujours un webmail, pas un service de microblogging (par exemple).

      ce commentaire est sous licence cc by 4 et précédentes

  • # Merci!

    Posté par  . Évalué à 4. Dernière modification le 22 août 2012 à 12:25.

    Merci pour cet excellent journal, qui est une suite logique et factuelle de mon journal un brin provocateur sur le mode de licensement de Warsow.

    Faire un jeu forkable ne signifie pas que le fork soit un jour effectif. Un jeu qui ne forke pas est un jeu dont l'équipe de développement a une ligne directrice claire et établie, et qui a un développement vivant.

    Ca résume grosso-modo mon opinion (que je n'ai pas exprimée auparavant) sur les forks, mais, comme Zenitram au dessus, j'émets quelques réserves au sujet des forks facilités sur la plate forme Windows.

    Mais pour revenir à nos forks de moteurs de jeu, on peut reconnaître que beaucoup de temps et de ressources sont probablement gaspillés, mais là encore, l'argument du fork n'est pas recevable : les moteurs de jeu ne sont forkés que lorsque le jeu est déjà forké.

    Je ne connais pas vraiment le monde du développement propriétaire, mais parmi les moddistes amateurs qui travaillent principalement sous Windows, y'en a pas un ou deux dans la salle pour se dire que travailler ensemble sur le moteur du jeu c'est moins d'effort et de ressources gachées? Si ils sont capables de s'organiser au sein d'un projet pour les artworks, pourquoi ne seraient-ils pas capables de le faire pour le moteur du jeu? En somme, ce serait pas le signe d'une tres mauvaise gestion du projet, qui conduira inévitablement vers un fork… et la boucle est bouclée! Un genre de fork récursif peut être? :D

    • [^] # Re: Merci!

      Posté par  (site web personnel) . Évalué à 1.

      Idem, un grand merci pour cette dépêche et surtout pour l'analyse qui y est faite. J'ai eu beaucoup de plaisir à la lire !

      kentoc'h mervel eget bezan saotred

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.