Romain Vinot a écrit 125 commentaires

A mon avis 15Go, ça correspond à l'intégralité de l'historique (donc la taille du repository subversion sur le serveur), pas à la taille d'un checkout.

Je comprend le point de vue. Finalement, le problème des brevets logiciels fait simplement ressortir de façon plus frappante un défaut qui existe dans tous les cas.

Donc, dans le cas des "industries matérielles", on tolère la chose parce que "ça fait plaisir aux industriels et que ça nous gêne pas", et quand on se met à toucher aux logiciels où l'impact est plus important pour nous, on n'est plus d'accord.

Mais je reste sur ma position. D'un point de vue philosophique, on ne peut pas être pour dans un cas et contre dans l'autre. Ce qui revient à dire, à mon sens, que la FFII demande tout simplement la révision du système complet des brevets ! (c'est moi qui dit ça. Oui, c'est encore une fois exagéré pour bien comprendre la position de chacun)

En quoi l'application d'algorithmes mathématiques dans un logiciel pour obtenir un effet technique innovant diffère de l'exploitation de l'application de principes mécaniques ou chimiques connus dans une procédure pour obtenir un effet technique innovant ?
Visiblement tout le monde conteste le premier mais personne le second. Pour moi c'est strictement la même chose et personne ne m'a convaincu de la nécessité d'une différenciation ici.

Je plussoie largement cette phrase ! J'ai le même avis qu'Eric sur la question. ca fait 1 an que je planche dessus et personne ne m'a encore fourni d'arguments valables face à cette question précise !

Allons jusqu'au fond de ma pensée : je jouais l'avocat du diable en essayant de montrer que le problème des bevets est le même que l'on soit dans l'industrie automobile ou dans le logiciel. Je suis personnellement contre dans les deux cas. Je ne comprends toujours pas le point de vue de ceux qui sont d'accord pour mettre des brevets dans un système de guidage pour automobile et pas dans les logiciels.

D'après ton point de vue, la différence est que dans les logiciels il est possible de faire quelque chose de façon individuelle alors que dans le cas de l'automobile non. Donc sous prétexte qu'un individu peut faire une invention, tu considères que les grands "labos" de recherche ne peuvent pas protéger leur recherche par les brevets. C'est n'importe quoi comme argument.

Mais les brevets sont faits pour protéger les investissements en recherche & développement. Or, on ne peut pas nier qu'il y a autant de sommes investis en R&D dans le logiciel que dans l'automobile. Donc pourquoi vouloir empêcher l'investissement dans le logiciel de fructifier grâce aux brevets ?

Certes, on peut dire que les brevets ne sont pas la bonne solution pour protéger les investissements en R&D (ce sur quoi je suis d'accord). MAIS CA NE REPOND TOUJOURS PAS A LA QUESTION INITIALE : qu'est-ce qui différencie l'industrie automobile de l'industrie du logiciel ? Pourquoi les brevets sont-ils bien dans un cas et mal dans l'autre ?

Interoperability is about how different software systems work together

Ce qui peut aussi se traduire en : "L'intéropérabilité c'est comment Outlook, Word et WMP travaillent ensemble !"

Je ne trouve pas que ce se soit une interprétation tirée par les cheveux. Après tout, le fait de faire interopérer Outlook, Word et WMP ensemble est un but louable, qui, du point de vue des utilisateurs, apportent effectivement un plus. Donc, cette phrase n'est pas choquante.

Bon, après, ce n'est pas le sens que tout le monde donne à interopérabilité.

Pourtant j'imagine que l'on brevète bien les fameux systèmes d'autoguidage. Les trucs qui permettent aux voitures de suivre l'autoroute toute seule à la bonne vitesse et sans faire de collision.

Donc tu brevètes l'interface entre le système de radioguidage et le machin électronique dans la voiture qui utilise les signaux pour se guider. Ce qui signifie que pour utiliser une voiture qui gère ce type de signaux, il faut une voiture d'un constructeur ayant payé des royalties pour utiliser le brevet. Et ça ne choque pas plus que ça en général...

C'est pas un peu contradictoire avec la nouveau centre de recherche de l'INRIA sponsorisé par Microsoft ?
Celui où le représentant de Microsoft a indiqué : "aucun logiciel ne sera mis sous licence GPL dans ce labo !"

Moi, je serais pas aussi convaincu. Les stats de Xiti sont fait le week-end alors qu'il y a traditionnellement plus de Firefox le week-end qu'en semaine (parce que les individus sont en train de passer à Firefox, mais pas les entreprises), la différence est significative, de l'ordre de 3 à 4%.
De plus, les résultats de Xiti sont traditionnellement à l'avantage de Firefox par rapport à d'autres site de monitoring (onestat et l'autre dont je me souviens plus le nom). De ce que je vois, dans les payx émergents, Firefox fonctionne bien, en Europe c'est pas si mal que ça. Et le pire, c'est bien les US qui restent encore à fond pour IE. Les denrières stats donnaient Firefox à 8% au lieu de 13% et surtout avec une progression en baisse (autrement dit on aurait atteint la cible des geeks aux US et le reste ne suit pas).
Bref, je brosse un tableau un peu moins beau que tout ce qui est indiqué ici. La vérité est sûrement entre les deux.

D'autre part, Renault n'a jamais fait faillite en permettant à ses clients de regarder sous le capot de leur bagnole, que je sache.

Seulement Renault ne serait pas très content si tu pouvais, après avoir acheté ta voiture, la cloner pour gratos et refiler le clone à qui tu veux dans la rue.

Et que dire de la valeur ajoutée apportée par un développement collaboratif de plusieurs milliers de personnes à travers le monde ?

Pour qui ?
Pour l'utilisateur ? C'est clair que c'est beaucoup mieux ! (et on est d'accord que tout utilisateur ne devrait utiliser que des softs libres)

Pour l'entreprise qui développe le logiciel ? Je vois pas. Déjà, les milliers de contributeurs vont se volatiliser dès que tu leurs dis que tu vas faire de l'argent sur leur dos (par exemple en vendant du support sur le code qu'ils auront écrit). Ensuite, l'entreprise va perdre la main mise sur l'évolution du logiciel. Regarde Fedora, Redhat veut garder la main mise sur l'évolution du produit, ben certes c'est GPL, mais y a pas trop des milliers de contributeurs. Open Office non plus. Mozilla, ex-Netscape qui a plus une culture d'entreprise que de communauté, non plus. Le cas du kernel et de Gnome est intéressant. Je pense que ça marche car il y a plusieurs entreprises derrière le produit (et non pas une seule) et que ces entreprises se sont plus ou moins implicitement alliés face à une menace plus grande : Microsoft et Windows.

Je suis convaincu que Carmack (ou plutôt sa société) assure un support sur son moteur, et que ce support est non trivial.

Ce n'était pas le cas il y a 5 ans à l'époque du moteur de Quake et Quake 2 (qui a quand même équipé beaucoup, beaucoup de jeux). A cette époque là, la vente du moteur, c'était les sources du jeu Quake. Point. (j'avais lu ça dans une interview d'un développeur de jeu qui avait acheté la licence du moteur).IdSoftware fournit les sources et c'est tout. A chacun de prendre en main le machin et en faire ce qu'il veut.

Depuis, il y a le moteur d'Unreal qui est arrivé, la revente de moteurs est devenu lucrative, donc j'imagine que c'est un peu plus propre et que le packaging est un peu mieux fait.

Il n'empêche que lorsque tu vends le moteur, tu vends clairement le logiciel, les algorithmes qui sont dedans. Tu achètes donc l'expertise du gars qui a pondu le moteur (en l'occurence Carmack).
Il n'y a pas de support à faire.

Ca marche comment la GPL, là ?

Pour moi, le coup du moteur/artworks, c'est un peu le même problème que les entreprises qui vendent des libs. Tu vends des "choses " qui servent à écrire des programmes (des libs ou un moteur).

Ben, du coup, le principe de la double licence fonctionne très bien. Tu fournis une version GPL que tout le monde peut utiliser à condition de livrer le soft réalisé en GPL également, et une version propriétaire payante pour ceux qui veulent faire des softs propriétaires avec.

MySQL et QT s'en sortent, ma foi, très bien.

Par contre, c'est une solution qui fonctionne car il existe encore des logiciels propriétaires. Dans le cas de notre utopie où il n'y a que des logiciels libres partout, ça marche plus.

Je trouve le système de licence libre parfaitement bien. Sauf que l'entreprise qui développe son logiciel sous ces deux licences ne peut pas utilisé du code GPL, puisqu'il ne peut pas l'incorporer dans sa licence proprio. Et c'est bien le cas d'ailleurs : QT et MySQL sont des gros blocs monolithiques qui ne réutilisent absolument pas le travail des autres.
Donc le système de double licence ne résoud absolument pas le problème posé par la dépêche : la GPL reste, en un sens, virale.

En même temps, les invitations Gmail, ca ressemble un peu à du spam. Quand tu regardes le contenu, c'est "bonjour monsieur que je ne connais pas, j'ai une super nouvelle pour toi, un service gratuit tout ça, rien que pour toi. Voici une invitation personnelle. Clique-là."

Je peux comprendre que l'invitation gmail soit considéré comme du spam. Quand je reçois du courrier de ce genre, j'aime que ce soit classé comme spam. Donc bon...

Voir même maintenant que les invitations sont quasiment illimitées, c'est de plus en plus du réel spam (ce qui est un peu la proposition initiale du journal d'ailleurs...)

En même temps, le repository global de KDE est au moins aussi gros que celui du noyau. Certes, c'est découpé en de nombreux programmes, mais le noyau c'est découpé en module. De toute façon, quand tu codes, tu codes sur un fichier à la fois.

Le commentaire suivant sur les méthodes de management de branche, etc est bien plus génant que les problèmes de performance amha.

Ben, l'idée c'est que à partir d'un moment, le signal peut déjà être reconstruit parfaitement, donc ça sert plus à rien d'échantilloner plus.

Et quand tu es aux Etats-Unis (et bientôt aussi chez nous avec l'EUCD), la loi te dit que tu n'as PAS LE DROIT d'utiliser DeCSS pour décrypter tes DVDs car cela est un contournement de mesures techniques.

Quand tu achètes un DVD; tu as l'obligation d'utiliser un soft approuvé (ie: qui a reçu la licence des majors pour faire le décryptage) par les majors pour le lire. Donc ton player mplayer ou xine est illégal. Aux Etats-Unis pour le moment et bientôt chez nous.
De même que le pyMusic est à la limite de la légalité.

Les deux servent bien à l'interopérabilité néanmoins.

Hors les licences libres protègent justement le développeur dans le sens où il garde tous les droits sur son développement. Donc peut-être pas payé rapidement, mais peut-être très longtemps...

Je ne comprends pas bien la relation entre la licence d'un logiciel et le fait d'être salarié par une entreprise ou non pour déveloper le-dit logiciel.

Tu peux très bien être payé par une entreprise pour développer du logiciel libre. Le copyright de ce que tu écriras sera toujours à l'entreprise qui t'emploie (en particulier, tu ne pourras pas changer la licence de GPL à BSD ou vice-versa à ton gré), tu n'en es pas l'auteur.

Ca n'a donc rien à voir avec le fait que les licences soient libres ou pas.

Et vous trouvez ça beau, vous ?
Bon d'accord, c'est hautement personnel... Je ne supporte plus les interfaces en une seule couleur comme BlueCurve de RedHat ou le Galaxy de Mandrake où tout semble gris. Là, tout semble marron. J'aime les interfaces avec des gradients et où tous les widgets ont des couleurs légèrement différentes, mais lisibles.

Plus précisément, le thème du window manager est immonde je trouve. On a l'impression d'avoir perdu au moins 10 ans ! Et alors la couleur identique au fond pour les fenêtres non-focus, vous trouvez pas ça bizarre ?

Par contre, j'aime bien les boutons, checkbox et tab. Dommage on voit pas d'ascenceur dans le screenshot, or les ascenceurs c'est une partie non négligeable d'un thème pour moi.

Pourquoi y-a-t-il des macros dans le fichier OpenOffice "10 raisons d'utiliser OpenOffice.org ?" ?
Lorsque j'ouvre le fichier, il me demande : "voulez-vous autoriser l'exécution des macros de ce fichier ?".

Quelqu'un a-t-il des échos du paquet amarok pour Gentoo ?
Nous en sommes toujours à la version 1.0. La version 1.1.x est marquée comme unstable depuis toujours. Pouvous-nous espérer avoir la 1.2 prochainement ?
C'est vraiment dommage cet Amarok, c'est l'un des softs que j'utilise le plus, et justement il n'est pas à jour sur Gentoo...

http://packages.gentoo.org/search/?sstring=amarok(...)

Je voulais juste indiquer que l'idée même d'un scénario pour des tests unitaires, c'est pas logique dans le sens où les tests unitaires sont sensés être indépendants, non ordonnés, etc. C'est la philosophie de JUnit et beaucoup de principes de fonctionnement de ce framework viennent de cette philosophie, que tu mets à la poubelle avec ton JUnitScenario.

Donc le JUnitScenario n'est pas conforme à la philosophie de JUnit. Et alors ? La belle affaire ? Qu'est-ce j'en ai à pêter ? Heu bah rien, c'était juste pour discuter :)

Comme j'ai la vague sensation que ça commence à tourner un peu en rond, je vais arrêter la conversation là, ça vaudra mieux que de se répeter encore et encore...

"Quand tu exécute 2000 tests et que tu veux pouvoir les exécuter en moins d'une minute"
Ca ne m'interesse pas dans le cadre du développement d'applications métiers...

Non. ca ne t'intéresse pas dans le cadre des tests que tu réalises. Ca n'a rien à voir avec le fait que le développement soit d'application métier ou pas (ce qui d'ailleurs ne veut pas dire grand chose, y a quelqu'un qui développe autre chose que des applis métiers ?).

On a une tache init qui regénère la base, insière les donénes de config et lance le tout... on peut à tout moment relancer tous les tests de l'application.. sans prérequis ou config spéciale....

Et si je veux exécuter UN test unitaire ? J'ai un bug quelque part, j'ai déterminé dans quelle classe il était, je crée mon test unitaire qui va bien et je veux exécuter juste celui-là. Je fais comment avec ton système ?

Ca montre bien que ce ne sont pas des tests unitaires que tu fais mais plutôt des tests de recettes ou des tests de fonctionnalités !

Bien sûr, tu peux tester des services indépendamment des applications développées au-dessus de cette couche. Ce qui est plus dur, c'est de tester des services indépendamment des autres services situés en-dessous de cette couche (en particulier la couche persistante d'accès aux données).

Pour la BD, son accès est lent (comparativement à un accès direct en RAM). Quand tu exécute 2000 tests et que tu veux pouvoir les exécuter en moins d'une minute (c'est un des pré-requis de la méthodologie TDD), bah, avec une BD ça va pas être possible.

En plus, les tests unitaires, il est hautement conseillé de les rendre indépendant les uns des autres et de l'environnement. Ce sont des tests standalone (D'où le coup du setUp et du tearDown qui sont exécutés A CHAQUE TEST). Avec la BD, ce n'est pas possible. Tu ne peux pas générer une BD propre pour chaque test.

Mais encore une fois, tout cela ne concerne que la vision spécifique des amateurs de TDD, ce n'est pas la tienne, c'est tout. Mais bon, j'aime bien quand même cette conversation alors je continue :)

Pas du tout d'accord, ma définition est claire, les tests unitaires servent surtout pour nous à valider les fonctionnalités de l'application pour s'assurer que tout ce qui sera développé fonctionnera correctement.

Ok, mais chaque utilisateur de JUnit a sa propre définition de test unitaire et s'en sert à sa manière.

L'utilisation "orthodoxe", celle mis en exergue par les auteurs initiaux de Junit et du TDD (Test Driven Development) n'est pas la même définition que la tienne. Pour eux, un test unitaire doit tester une partie de code et non pas une fonctionnalité. D'où l'utilité de objets bouchons (stubs), des Mock et autres bizarreries. Pour tester une fonctionnalité, il ne faut clairement pas utiliser d'objets stubs, puisque ça modifie clairement l'environnement qui n'est plus comme un serveur de production. Par ailleurs, l'accès à la BD est un problème récurrent. Pour faire du TDD et lancer les tests 3 fois par heure, tu ne peux pas te permettre d'accéder à la BD pour les 2000 tests qui tu as écris.

Plus d'infos sur http://www.junit.org,(...) http://www.easymock.org,(...) ...

Maintenant, ton utilisation de Junit est parfaitement valable pour tes tests de fonctionnalités que tu appelles tests unitaires. Chacun fait ce qu'il veut avec l'outil qui lui convient et tout est bien dans le meilleur des mondes :)

Bah moi, je suis toujours pas convaincu. Les tests unitaires permettent de tester non pas une fonctionnalité mais une unité de code. Typiquement, quand tu veux faire un test creerClient, tu ne crées pas vraiment le client dans la base de données, tu crées un objet Mock de ta base et tu vérifies que ton code Java génère bien les requêtes SQL correctes. Il ne s'agit pas de tester que ton moteur de BD fait bien l'insertion correctement, on suppose que la BD sait le faire.

Donc les tests unitaires ne permettent pas du tout de tester une appli réelle. Il y a les tests de recettes qui sont fait pour ça.

Après, effectivement, on peut utiliser des outils de type JUnit pour créer des tests de recettes (dont une partie peut être des tests de charge), mais il ne faut surtout pas dire que JUnitScenario permet de réutiliser les tests unitaires pour faire des tests de charge. C'est une grosse erreur et contribue au flou qui entoure la définition d'un test unitaire.

Pour info, il existe HtmlUnit qui utilise le framework JUnit également et dont le but est de simuler un navigateur web qui permet de faire des tests de recettes de façon très simple. Mais attention faire des tests de recettes automatiques, c'est autrement plus compliqué que des tests unitaires automatiques.