arnaudus a écrit 5382 commentaires

Bah, ça s'apparente à de la mauvaise gestion. Si c'était du harcèlement que de ne pas donner les droits root à tout le monde, ça se saurait :-)

Il faut quand même apprécier l'ingéniosité des assembleurs et des producteurs de logiciels pour contourner à la fois la loi et les licences existantes afin de d'atteindre de manière la plus discrète possible la liberté de leurs propres clients. Pense à tous ces noyaux linux qui tournent sur une majorité de smartphones, de tablettes, de TruxBox, tous ces beaux logiciels libres dont tu peux tout à fait récupérer les sources, mais pour lesquels tu ne peux ni vérifier que tu exécutes bien les binaires compilés à partir de ces sources, ni modifier et redistribuer… Tout ça avec la bénédiction de la répression des fraudes, et sans soulever de vagues de protestation parmi les consommateurs. Ils sont très, très forts, et leur détermination (ainsi que leur force financière) fait que, sans base législative ultra-forte, la lutte promet d'être très difficile.

Au lieu de militer contre telle ou telle technologie, ce qui est perdu d'avance étant donné l'accumulation de nouveaux projets liberticides, il serait beaucoup plus sain d'interdire purement et simplement la vente d'équipements munis de dispositifs non-contournables visant à empêcher le consommateur d'utiliser le produit comme il le souhaite.

D'un autre côté, si le problème des jeux libres n'était que l'artwork, on ne serait pas si mal. Il y a une tripotée de jeux libres qui sont instables, pas finis, bourrés de bugs, pas multiplateforme, etc. J'imagine qu'on peut ajouter à la liste des problèmes le fait que l'équipe de développement est souvent composée de gens qui ne sont pas des programmeurs professionnels, qui font des mauvais choix techniques dès le début, et qui ont du mal à gérer un projet, avec des releases, des périodes où on ne fait que corriger les bugs sans ajouter de fonctionnalités, etc.

Le problème de l'artwork reste réel, cependant. Il y a relativement peu de gens compétents dans le domaine, et encore moins désirent passer du temps sur un projet libre. Maintenant, l'ambition dévorante des gens qui lancent des jeux, l'idée de produire un jeu complet à partir de rien, est probablement irréaliste et déraisonnable, et reste à l'origine de beaucoup d'échecs. Beaucoup de jeux ont par exemple des musiques dégueulasses, alors que la musique, si elle contribue à l'ambiance du jeu, n'est pas un élément bloquant. Pourquoi ne pas réutiliser les musiques libres existantes (jeux libres, enregistrements de musique classique libres)? Ça permettrait de se concentrer sur les aspects fondammentaux, et ça serait tellement plus agréable pour les joueurs! En plus, ça permettrait de se culturer en musique classique, plutôt que de se pourrir les oreilles avec de la bouillasse.

Ah oui, B FW = Battle for Wesnoth :-)

C'est un peu facile de balancer des critiques quand on ne fait rien, mais je trouve que le paysage des jeux libres est un petit peu déprimant. À part BFW, qui est un modèle du genre, j'ai un peu l'impression que les jeux libres sont soit des mini-projets bien finis (type frozen bubble), soit des trucs ambitieux jamais fignolés. Des trucs somme "sable" par exemple sentent bon les années 1990, le jeu n'a plus de page officielle, il est mort. Des projets très intéressants, comme OpenTTD, Freeciv, Freecol, Lincity, se trainent un peu comme des limaces et ne sont soutenus que par des équipes très réduites, dont la plupart aimeraient certainement passer le flambeau et se consacrer à autre chose. Même des jeux super innovants comme globutaion semblent à l'arrêt. Est-ce que ça veut dire qu'on a atteint la limite de la "niche écologique" des jeux libres? Étant donné le nombre de joueurs dans le monde, c'est fou qu'aucun projet d'envergure avec un budget conséquent n'apparaisse.

Ce n'est pas prouvé qu'ils ont plus de chance.

Une preuve statistique est considérée comme suffisante par les scientifiques qui ont eu la chance ou l'intuition de quitter les cours de maths le plus tôt possible.

Oui, rien à voir, mais n'empêche, blanc c'est bien, et noir c'est mal. Pareil pour la magie blanche, pareil pour une explication claire ou obscure. Aux échecs, les blancs jouent en premier et ont plus de chances de gagner. À force, j'imagine qu'on peut mal le prendre si on est noir ET parano (ou qu'on broie du noir :-S).

Après, on doit pouvoir trouver quelques exemples contraires. Les mariages blancs? Mais on ne parle pas de mariages noirs. Mine de rien, les termes de "blanc" et "noir" sont connotés. J'ai souvenir de cette expérience terrible menée auprès de gamins de 5-6 ans, auxquels on donnait une série de visages qui ne différaient que par la couleur, et on leur demandait "lequel a des bonnes notes à l'école", "lequel veut devenir médecin", et les réponses étaient incroyablement racistes. On n'y peut pas grand chose, mais c'est comme ça.

L'avantage de passer par une lib telle que la STL, c'est de pouvoir utiliser tout ces algos "de base" avec des opérateurs personnalisés, ce qui est bien pratique quand on veut trier des choux-fleurs.

C'est sûr, mais (i) est-ce que ça arrive si souvent que ça de vouloir trier ou additionner des choux-fleurs, par rapport à trier ou additionner des nombres ou des chaines de caractères, et (ii) techniquement, je ne vois que peu d'exemples où on veut réellement trier des choux-fleurs selon leur chou-fleuritude : on veut les trier selon leur taille, selon leur couleur, selon tout un tas de trucs qui s'expriment par leur valeur numérique.

Après, je ne critique pas l'existence d'une STL, qui reste un outil utile dans des cas assez spécifiques. Ce que je critique, c'est le paradigme de programmation qui consiste à faire des appels non-standard à des fonctions triviales dont tout le monde a besoin, et qui elles font des appels à la bibliothèque standard.

Par exemple, M. Dupont va programmer une fonction somme(iterator, iterator) qui va appeler std::accumulate; alors que M. Smith va programmer une fonction sum(vector) qui va appeler std::accumulate. Bref, les deux ont les mêmes besoins, ils appellent les mêmes fonctions standard en arrière plan, mais leur interface n'est pas standard. Ça duplique les efforts, ça rend le code plus difficile à maintenir et à lire, les fonctions résultantes ont peut-être des bugs ou elles ne sont peut-être pas optimales. Je ne vois pas du tout l'intérêt d'intercaler les couches de trucs standard et de trucs non-standard.

Il est évident que si la bibliothèque standard possède des fonctions min() ou sum(), elles ne vont pas toujours se comporter comme le programmeur souhaiterait qu'elles se comportent. Dans ce cas, il faudra de toutes manières repasser par la STL ou équivalent, avec un commentaire du style // je veux le plus petit élément qui ne soit pas 0, alors que la fonction min() renvoie 0. Mais dans 95% des cas, ces fonctions se comporteront exactement comme il faut, et ça fera gagner un temps fou à tout le monde. Je trouve déraisonnable d'estimer qu'un programmeur sur un langage bas-niveau n'a que ça à faire que de chercher dans la littérature l'algorithme optimal pour réaliser telle ou telle tâche triviale.

Ce sont des langages système, donc de bas niveau.

C'est exactement le sens de ma remarque. D ne sera probablement jamais utilisé pour coder un système d'exploitation ou un pilote de périphérique. Si on regarde l'utilisation de C++, c'est principalement du logiciel utilisateur (bureautique, logiciels spécialisés, etc). Dans mon domaine, le C et le C++ sont utilisés principalement pour coder des modèles "maison" (simulations, etc) quand les langages haut niveau sont trop lents. Au passage, matlab est un peu déprécié en biologie, les gens préfèrent de plus en plus R.

Les langages C/C++/D ne sont pas faits pour manipuler des vecteurs (au sens mathématique)

Les vecteurs de caractères ou de chaines de caractères n'a aucun sens mathématique, et pourtant, ils sont manipulés par le langage.

Le problème, à mon avis, ne vient pas vraiment du "niveau" du langage, mais du présupposé sur l'utilisation qui en est faite. Un langage bien foutu devrait pouvoir être utilisé par tout type d'utilisateur, et ce n'est pas le cas, ni pour C, ni pour D. Quelqu'un qui veut faire des choses très simples ne devrait pas avoir à récupérer un char** en argument du main() (en gros, on devrait pouvoir utiliser le langage sans pointeurs), et la librairie standard devrait permettre tout un tas d'opérations de base sans avoir à les recoder soi-même : min(), max(), sum(), mean(), il me semble un peu ridicule de passer par une STL (ou équivalent) pour des opérations aussi triviales.

Je ne comprend pas vraiment où tu veux en venir. Le compilateur ne peut pas deviner que tu veux utiliser const, je ne vois donc pas de solution, à part ne pas l'utilisé, mais c'est aussi possible.

Tu dis que c'est difficile ou que c'est impossible? Il me semble que

double square(double x) {return x*x;}

peut être sagement tagguée "const" par le compilo, qui peut décider quels appels de fonction sont const et lesquels ne le sont pas. Après, j'ai l'impression que la philosophie de D est de mettre le curseur à peu près à mi-chemin entre le compilo et le programmeur, le compilo peut deviner quelques trucs, mais l'aide du programmeur est indispensable à l'optimisation poussée, en explicitant la structure du programme : telle partie ne change pas, cette fonction ne peut pas lancer d'exceptions, etc. Je ne vois pas dans quelle mesure c'est fondamentalement différent de ce qui se passe en C ou en C++, par exemple.

void est un type incomplet, en particulier on ne peut pas écrire void x pour déclarer un argument de type void à une fonction;

Mmmh, c'est pour bricoler des trucs avec des templates? Parce que je ne vois pas trop ce que tu peux faire du x, la variable n'a aucun sens, si?

string toto = sprintf("Bonjour %s. Vous avez %i nouveaux messages",name, 3);

toto << "Bonjour " << name << ". Vous avez " << 3 << " nouveaux messages.";

Franchement, tu trouves la première plus lisible? Et de toutes manières, même à lisibilité égale, l'inférence de type est un avantage indéniable (recourir au programmeur pour une tâcha automatisable n'a aucun intérêt).

D'ailleurs, j'imagine que la deuxième instruction peut être algorithmiquement transformée vers la première par le compilo. C'est donc le langage qui impose une construction lourde.

la concaténation successive de chaînes c'est très suspect, algorithmiquement, comme opération

C'est dommage que les gens en aient besoin, hein.

size_t moyenne = reduce!("a + b")(0, tab) / tab.length;

Ah ouais, c'est limpide comme syntaxe. C'est exactement le même brainstorm que la STL C++ : un truc potentiellement puissant mais illisible.

Ma critique, c'était justement que le langage soit apporter un minimum de fonctions de base. Bien sûr qu'on peut recalculer une moyenne ou une variance à la main, on peut même créer des méthodes pour le faire, on peut même créer sa propre bibliothèque de gestion de vecteurs, avec des vector_int, vector_double, ce qui permettrait de faire des vec.sum() et des vec.mean(). Mais on s'en fout, ce qui est crucial, c'est que le langage vienne avec ça, parce que ça fait partie de ce qu'on fait tous les jours avec des vecteurs. Là, le langage vient tout nu, c'est un truc McGyver. À chaque début de projet, tu réinventes la roue, avec éventuellement des bugs ou des problèmes de performance. Ça me semble totalement inutile, et en plus c'est illisible.

C'est clair qu'à la place de supprimer la complexité, on peut simplement la cacher. Mais regarde le main() de D : on a déja un string[]. C'est mieux qu'un char** (!!!), mais on ne récupère pas non plus quelque chose de manipulable : par exemple, que donne un writeln(args)?

Ceci dit, c'est peut-être aussi que les exemples choisis sont étranges. Ces types size_t semblent très mystérieux, et le premier exemple propose déja des immutable et des pure nothow, alors que ces mots-clé ne sont peut-être pas indispensables ici?

Tout est un peu dans le titre. J'ai l'impression que les devs système sont finalement assez satisfaits de C, et que C++ est difficilement détrônable sur le reste. Quoi qu'il en soit, je retrouve dans D tout un tas de choses que je trouve archaïques, et que seuls les devs C ou C++ comprennent, car ils se sentent à l'aise avec.

Une première chose est la verbosité des déclarations. Finalement, les histoires de "@safe pure nothrow" ne sont que des commandes d'optimisation, que l'on utilise principalement pour aider les compilos. Je ne suis pas certain que ça soit au programmeur de gérer ça. La raison principale est que, selon mon expérience, ça nuit à l'évolution et à la flexibilité du programme. Je ne connais pas assez D, mais en C++, on se tape des arbres super-complexes de const à gérer ; modifier le status "const" d'une variable est quasiment impossible dans un programme complexe, le compilo hurle avec des milliers de messages d'erreur, et on finit par saloper le design avec des mutable, et/ou par dupliquer toutes les méthodes avec une version const et une version non-const strictement identiques. Je pense que les langages doivent aussi être conçus pour les gens qui ne sont pas des experts en programmation, y compris en évitant au maximum de faire faire le boulot du compilo aux programmeurs.

L'autre truc qui me fait vraiment reculer, c'est le fait que les tableaux sont gérés comme en C comme des pointeurs. Alors oui, c'est élégant et rapide, mais ça demande un mode de réflexion qui n'est pas naturel pour la plupart des gens, ça rend le code lourd, et surtout, ça induit un mode de programmation basé sur les boucles (indentations récurrentes, définition de variables temporaires qui s'appellent "i" ou "x" et qui ne sont parfois pas réutilisées… Alors c'est sûr, on a toujours tout un tas de bibliothèques externes qui implémentent des vecteurs et des matrices, mais, à mon avis, la présence de ces bibliothèques ne fait que confirmer le manque de gestion des structures simples par le langage (sans comper que l'utilisation correcte de la STL nécessite une expertise assez hallucinante).

Typiquement,

int tab[] = [1, 2, 3];
tab = tab + 1;

signifie, pour un être humain normal, [2,3,4]. Alors oui, c'est certain, un cerveau est assez flexible pour comprendre que ça n'est pas le cas et d'apprendre comment faire une boucle à la place, mais je ne comprends pas comment on peut encore se retrouver avec des langages qui ne gèrent pas intuitivement la concaténation de caractères

string toto = "Mon prénom est " + "Toto";

ou la manipulation de vecteurs

double moy = sum(tab)/size(tab);


Je me demande s'il n'y a pas un peu d'obfuscation volontaire de la part des gens qui créent et utilisent des langages basés sur des concepts qui ont 30 ou 40 ans, et qui, finalement, sont bien contents de se sentir supérieurs grâce à leur compréhension intuitive des std::const_iterator<std::vector<double> > obj.begin(). On crée D, E, F, G, H ou I avec la volonté d'être moins verbeux, mais finalement, on ne fait que changer le langage en laissant les habitudes inchangées.

Le PP se veut un parti ni de gauche ni de droite : tu as déjà vu ça quelque part n'est-ce pas ?

Mouais, alors on a les mouvemente qui sont et de droite, et de gauche (national-socialisme), les mouvements qui sont entre la droite et la gauche (centrisme), maintenant, on a les mouvements ni de droite, ni de gauche… Pas de contenu, quoi. M'étonne pas que ça ne prenne pas.

N'importe quoi, comment peut-on encore propager cette légende urbaine? J'emprunte 100€ à 10% par mois avec des mensualités de 20€.

1er mois : je rembourse 20€, 10€ de capital, 10€ d'intéret. Il rest donc 90€ à rembourser. Le mois suivant, je rembourse 20€, 9€ d'intérets, 11€ de capital. Il reste 79€ à rembourser. Le mois suivant, 7.90€ d'intérets, 12.10€ de capital. Il reste 66.90€, etc. Donc à mensualité égales, on rembourse de plus en plus de capital, et c'est tout à fait logique, il n'y a aucune entourloupe là dedans.

Merci :-) Je me demande bien comment on peut arriver à croire qu'une banque puisse faire des trous de cette manière. Il est évident qu'elle a le droit d'avoir des comptes négatifs, mais ce solde négatif est forcément une vraie dette dans le monde réel. Après, il existe plein de manières de jouer de manière à être le plus négatif possible sans que les autres ne s'en aperçoivent et continuent à confier leur pognon.

Je pense que tu délires complètement. Je me demande d'où vient cette idée que la création monétaire est "gratuite". Si une banque prête 1000€ et que cette somme n'est pas remboursée, ses comptes sont à -1000€. Si ta banque a été créée avec un capital de 10000€ par ses actionnaires, elle ne vaut plus que 9000€, les actionnaires ont perdu 1000€ de vrai pognon dans l'affaire. Et quand les comptes deviennent négatifs, ils faut emprunter à d'autres banques et à la banque centrale. Et quand ça devient tellement négatif que personne ne veut plus prêter, soit la banque fait faillite, soit l'État doit entrer dans le capital pour sauver les épargnants.

Les banques ne peuvent donc pas "fabriquer de l'argent qui n'existe pas", elles ne peuvent que "fabriquer de l'argent qui n'existe pas encore". C'est toute la différence, si l'argent qui n'existe pas encore n'existe pas du tout, alors la banque a un trou dans ses comptes.

L'exemple classique de la banque A qui prête 1000€ à la banque B et vice versa, et que les deux banques ont donc ainsi 1000€ chacune, est bidon : chaque banque a 1000€, mais chaque banque a aussi -1000€ dans ses comptes. On est donc dans la situation initiale, sauf que les banques ont simplement échangé des dettes contre du pognon circulant. C'est exactement leur rôle, on ne peut pas leur reprocher de faire ça.

Alors oui, on peut critiquer le système sur la base que les banques ont tendance à être beaucoup trop optimistes sur l'argent qui n'existe pas encore ; mais c'est justement l'origine de la crise.

Ça serait quand même pas mal de ne pas virer dans la parano débile. Les banques font faillite parce qu'elles ont trop prêté et surestimé le pognon qui n'existait pas encore. Mais la crise financière n'a fait que révéler la crise des dettes souveraines, qui, elle, est basée sur un mécanisme bien plus malsain : les États pensaient pouvoir vivre à crédit éternellement. Le jour où le pognon arrête de tourner, chacun commence à regarder ses comptes, tout le monde se rend compte qu'il serait peut-être temps d'arrêter de refiler du pognon à tout le monde. C'est clair que, finalement, la crise n'a fait que révéler les excès de confiance passés, on peut considérer que c'est un assainissement de la situation, mais l'assainissement risque d'être un peu douloureux…

Non mais je crois que ce n'est pas le problème. La question posée pour OpenArena est "Est-ce qu'un fichier .ogg sous licence GPL respecte la GPL" et la réponse est peut-être "non": si un fichier .ogg est l'équivalent d'un binaire, alors il manque les sources (fichiers lisibles par un être humain qui ont permis de fabriquer les .ogg). C'est la même chose pour les fichiers .png issus d'un rendu 3D par exemple, il manque les fichiers dans le logiciel original (qui peut être propriétaire) pour modifier confortablement les .png.

Ça n'a pas grand chose à voir avec le choix de la licence de ces fichiers. Le problème se pose quand ces fichiers sont sous GPL, mais quand ils le ne sont pas, il n'y a pas de problème.

La GPLv2 dit :

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

Ainsi que :

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Il est donc tout à fait possible de distribuer dans des répertoires distincts sur un support unique 1) le programme sous GPL, et 2) les médias sous une licence proprio.

À mon avis, le reste n'est que rumeurs, interprétations hasardeuses, et FUD. D'ailleurs, RMS lui-même soutient un modèle moteur libre / artwork proprio pour les jeux, ça m'étonnerait qu'il le fasse sachant que ça n'est pas compatible GPL…

Sans plus de précision, j'ai l'impression que c'est du pipeau. Il suffit de clairement indiquer les licences dans les fichiers de code et dans les répertoires des medias, ainsi que dans le fichier License à la racine.

C'est vrai mais la loi française est stupide sur ce point de vue : elle refuse la licence différente pour "l'artwork" et le moteur.

Je pense que c'est complètement faux, mais peut-être as-tu une référence?

un jeu n'est pas vraiment un outil, le status est un peu différent. C'est moins important qu'il soit libre.

Ce n'est pas important que les médias soient libres (cartes, images, animations, sons…), mais par contre, le moteur est un logiciel comme un autre, qui interagit avec le système, écrit et efface des fichiers, utilise les périphériques et le réseau. Un moteur libre est la seule garantie que ton jeu qui tourne en arrière-plan n'en profite pas pour zyeuter sur quels sites tu vas, pour regarder si tu n'aurais pas installé sans licence d'autres jeux du même éditeur, etc.

L'OS marche très bien, il n'a juste pas le bon driver.