boubou a écrit 1384 commentaires

Eh oh j'ai jamais dis ca :)

Oups, désolé, tu as dit que gcc n'offrait pas ça (ce qui est faux).

Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité

Oui, tu remarqueras que c'est exactement ce que je dis dans le post auquel tu réponds :-)

Euh ca fait quand même un moment qu'ils courraient après ;)

Non, ils courrent après Java, c'est à dire après les apis. La difficulté dans le clonage de Java, c'est l'api monstrueuse, pas la compilation. C++ est beaucoup plus difficile à compiler que Java, par exemple.

Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt...

L'intérêt, c'est l'occupation mémoire plus faible, la facilité de distribution, etc. Quant au bench que tu cites, c'est de la merde. Il faut vraiment être un âne (je ne parle pas de toi) pour utiliser des benchs qui tournent aussi vite et prétendre que c'est représentatif de quelque chose...

Bon, je te reponds quand même, finalement. Tu as écrit "D'une manière générale, rien n'empêche une implémentation libre de standard, sauf en cas de brevets logiciels." C'est faux, surtout à cause des premiers mots. Je n'ai pas dit que le problème des interfaces ou des marques s'appliquait à .NET, j'ai juste dit qu'il existait. Adobe a par exemple longtemps prétendu que la liste des mots clés de postscript était sous son copyright et qu'on ne pouvait donc pas implémenter un interpréteur postscript sans son accord (qu'il donnait de façon automatique, mais c'est un autre problème). Autre exemple, le fait que les api java comportent le mot java implique que Sun peut chercher des poux dans la tête de toute implémentation concurrente sans même évoquer de brevets (encore une fois, ce n'est pas un problème pratique car on obtient très facilement une licence d'implémentation de Java, c'est automatique quand on télécharge l'api). Autre exemple, on ne peut pas dire qu'on fait un compilateur Ada s'il ne passe pas certains tests.

La liste est longue. Le droit d'implémenter un standard n'est pas une chose automatique, même en l'absence de brevet.

c'est quand même plus gros/lourd/lent que d'avoir un code qui s'execute directement non ?

Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement. Par exemple quand tu as une interface X et une référence x vers un objet de type X, quand tu appelles une méthode disons f (x.f) la méthode réellement exécutée est choisie dynamiquement, ce qui pose des tas de problèmes (pas d'inline, look up dans une table, etc.). Une VM peut faire de l'analyse de code et supprimer le dispatch dynamique dans certaines conditions. D'autres exemples sont la gestion fine du garbage collector (réglage de certains paramètres au vol) ou encore la façon donc la VM .NET engendre les templates au vol (avec partage du code si nécessaire et spécialisation si ça peut apporter quelque chose en terme de performances).

Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc. En fait, il y a assez peu de choses qu'on ne peut pas faire sans VM, à condition d'intégrer un runtime dans l'exécutable, c'est à dire une sorte de bibliothèque chargée de fournir de façon transparente certains services. C'est ce système qui permet de compiler OCaml en natif.

En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM. L'intérêt d'une VM, c'est bien qu'elle a accès à un code de haut niveau (le code de la VM). Elle peut donc prendre des décisions fines sur ce code qu'elle ne pourrait pas prendre à partir d'un code objet, parce que le bytecode Java ou .NET est de plus haut niveau, tout simplement. Timaniac a quand même raison sur un point (ça lui arrive), c'est que la sécurité vient en partie de ce code de haut niveau qui est en général vérifiable : la VM peut s'assurer qu'il ne contient pas de buffer overflown et d'autres bugs qui pourraient mettre en péril son modèle de sécurité. Ce n'est pas parfait, mais ça offre un niveau de sécurité largement supérieur à celui des plugins écrits en C pour Gimp, par exemple.

Au final, le principal intérêt des VMs ce sont justement les performances, ce qui est assez paradoxal. L'autre intérêt, c'est la programmation en couche : développer une VM de base, ce n'est pas très difficile (il existe une bonne dizaine de JVM open source, par exemple), car ça reste de bas niveau. Quand la VM existe, développer un compilateur n'est pas non plus super difficile car la VM est de bien plus haut niveau que l'assembleur, par exemple. En gros, on a donc intercalé un niveau d'abstraction entre le hardware et le compilateur, ce qui est assez cool.

Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.

Argumente bon sang :)

C'est sur que tu argumentes. Les copyrights autour des headers ou des interfaces (.h en C par exemple) ne sont pas des choses très claires. Il n'est pas certain qu'on puisse implémenter une bibliothèque 100% compatible avec un header donné sans infreindre les droits des auteurs du header.

Et ? quel est le rapport avec ce que je dis ?

Le rapport est que AUJOURD'HUI les auteurs d'un standard du W3C ne peuvent pas avoir de brevets contraignants dessus, ce qui n'est pas le cas d'autres standards.

Si l'entreprise BrevetsLogiciels Inc. s'apercoit qu'elle détient un brevet que violent un standard du W3C ?

C'est la merde, et alors ? Ce que tu fais semblant de ne pas comprendre, c'est que Mono pose d'AUTRES problèmes que le problème standard des brevets logiciels.

Eolas ca te rappelle quelque chose ?

Oui, Eolas ça me rappelle ça : http://www.theregister.co.uk/2004/03/05/eolas_web_patent_nul(...)

Pour moi c'est autrement plus important. T'en penses quoi ?

Autrement plus important que quoi ? Les brevets sont un problème graves, nous sommes d'accord. MS cherche à en obtenir sur .NET, c'est donc grave. Pour les standards du W3C, il y a un danger EN MOINS c'est que les inventeurs ne cherchent pas à empêcher l'implémentation de leurs inventions. Mais bon, je me demande pourquoi je perds mon temps à te répéter ça, tu refuses de comprendre.

Oui et ? XML est en partie l'oeuvre de MS, HTML aussi, CSS aussi, etc.

Exact et ce sont des standards du W3C, donc MS NE PEUT PAS DEMANDER AUTRE CHOSE QUE DU ROYALTY FREE. Tu ne sais pas lire ?

Mono n'est pas simplement .NET, et n'est donc pas l'oeuvre de MS de toute façon.

Tu le fais exprès de répondre à côté ?

Oui et ?

Et les conditions de l'ECMA autorisent MS à faire du RAND, c'est-à-dire à demander du fric pour avoir une licence de ses brevets. Toi comprendre ?

Ah ? .NET c'est surtout l'intégration de nombreux technos au sein d'une même plateforme, c'est ce qui fait sa force, mais je vois difficilement comment c'est brevetable. Mais bon vas-y donne nous un exemple de partie "novatrice" que MS a breveté.

Lis la demande de brevet, je t'ai donné au moins 10 fois les liens.

Genre c'est la première fois qu'on a les mêmes conversations :)

Je corrige ta propagande.

Pourtant tu fais un papier (bien construit au passage) à la conclusion "tendancieuse" puisque tu conclus au danger des brevets logiciels sur Mono. Moi je vois pas l'intérêt de prendre Mono comme cas particulier.


Parce que tu ne comprends pas la différence avec d'autres cas, ce qui prouve que tu n'as pas lu l'article, ni mes messages d'au dessus. Dernière répétition : beaucoup de logiciels libres n'ont pas pour but de faire un clone 100 % compatible avec un logiciel propriétaire, potentiellement protégé par des brevets. Beaucoup de logiciels libres ne sont pas présentés comme l'avenir radieux de Gnome, etc.

tu n'élargi jamais ton raisonnement que tu appliques à Mono au reste des LL

Cf au dessus pour le cas particulier de Mono. Pour le cas général, relis l'article, je dis bien que les brevets logiciels sont dangereux.

MS a de nombreux brevets, ils peuvent très bien attaquer par exemple une implémentation de JVM qui viole un brevet (ayant conclu un accord avec Sun, ils n'attaqueront pas Sun)

C'est sûr que MS n'aurait jamais utilisé cet argument contre Sun au moment où ils se battaient comme des chiffoniers autour de Java (je mets un smiley :-)

pour moi c'est beaucoup plus dangereux comme position d'implémenter un produit concurrent à MS

Gni ? Java est antérieur à .NET et des implémentations open source de la partie qui rapporte du fric (J2EE) existent et dominent même le marché depuis longtemps. Je ne vois pas de quoi tu parles, donc.

Pourquoi ton papier ne parle pas de ça ?

De tes fantasmes ?

je suis pas du genre à dire faire de la pub "gratuite",

Ah, ah, ah. Genre les délires sur JNI au dessus ?

mon objectif est non pas de montrer que Mono est exempt de tout risque, mais qu'il est dommage de "s'acharner" sur un seul projet, alors que le problème est beaucoup plus général.

Oui, car tu ne comprends pas que Mono n'est pas Linux, car Mono est une copie 100% compatible d'un logiciel de MS, alors que Linux n'a jamais été une copie d'un Unix existant (je prends Linux comme exemple parmi tant d'autres). Le but de mon article, par exemple, était d'étudier les dangers liés à Mono, pas de gloser dans le vide sur le danger des brevets comme tu le fais. Faire du concret pas du vent.

MS peut être tout aussi dangereux avec ses brevets potentiels sur le XML (pauvre XHTML)

Non, car MS ext co-inventeur de XML au sein du W3C et qu'il a donc renoncé à demander autre chose que du royalty free sur ce standard. Tu es vraiment incroyable. Est-ce que ça t'arrive de lire ce à quoi tu réponds ?

Tu t'attaqueras après au format OpenDocument, qui doit bien en violer un tas également (encore XML, ressemblances avec MS Office, etc.)

Quel puissance dans l'argumentation ! Donc parce que certains logiciels libres pourraient courrir les mêmes risques que Mono, il ne faut pas parler de ces risques ou seulement le faire de façon globale ?

Bon aller, tu vas encore gagner, comme d'habitude, j'abandonne.

Moi je traduis juste tes sous-entendus

Il n'y en avait aucun. Il y a ici comme dans de nombreux endroits une incompréhension de l'impact des brevets sur les standards, je ne fais qu'essayer de passer un message.

quand tu parles du problème du mp3, c'est parcqu'une société a des brevets logiciels sur des algo liés au format mp3, et qu'elle peut donc vendre des licences d'utilisations, et de ce fait empêche une implémentation "libre".

Oui, exactement, et alors ?

D'une manière générale, rien n'empêche une implémentation libre de standard, sauf en cas de brevets logiciels.

Dans tes rêves. Il y aussi le problème des marques, la propriété au sens du copyright de certaines apis, etc. Ceci dit, le problème de .NET est bien lié aux brevets, au moins pour la partie standardisée. Pour la partie qui est propriété de MS, je pense qu'il y a d'autres moyens de protection.

Pas plus que le HTML peut être implémenté librement, pas plus que le standard XY peut être implémenté librement, etc. On est bien d'accord : les brevets logiciels ca pu, ca met en danger tous les logiciels libres.

Sauf que c'est beaucoup plus complexe que ça. Par exemple, les standards du W3C sont obligatoirement en royalty free. Les auteurs d'un standard W3C comme XML, HTML, etc. sont dans l'obligation 1) de révéler leurs brevets concernés par un standards 2) de fournir une licence royalty free. Pour l'instant, il n'existe aucun problème avec de très nombreux standards du W3C, comme HTML, XML, etc. Au contraire, il existe de gros problèmes avec d'autres standards comme mp3, mpeg4, la fat (dont le brevet n'a finalement pas été invalidé), etc.

Ce que je te reproche, c'est de toujours te réfugier, comme tous les fans béats de Mono, derrière des considérations générales sur les brevets pour défendre la possibilité d'une implémentation libre de .NET, alors que ce framework pose des problèmes spécifiques : 1) il est l'oeuvre de MS 2) MS défend maintenant sa "propriété intellectuelle" de façon assez sérieuse par diverses techniques dont les brevets (alors qu'historiquement ce n'était pas trop le cas) 3) .NET est très novateur sur certains points, ce qui rend possible des brevets sans prior art 4) MS a tenté de protéger l'API complète, même si pour l'instant le brevet n'a pas été validé.

Je ne sais pas argumenter ? Ben j'élargi juste ton raisonnement. Pour toi rien ne prouve qu'on peut implémenter librement .NET. Moi j'élargi pour montrer que c'est un problème général et pas spécifique à Mono. Enfin puisque tout est pourri, commencons par arrêter d'utiliser ce noyau Linux qui violent des centaines de brevets.

Le problème n'est pas spécifique à Mono, mais .NET pose des problèmes spécifiques, cf au dessus.

Ce que je n'aime pas, c'est qu'on soulève à chaque fois le problème des brevets logiciels pour Mono... Effectivement Mono a ce problème, comme tous les autres, et ensuite ?

Non, pas comme tous les autres, Mono vise à être la COPIE CONFORME d'un produit qui est au coeur de la stratégie de Microsoft. Si tu ne comprends pas qu'être la COPIE CONFORME de quelque chose est différent d'intégrer des éléments qui pourraient être brevetés, je ne peux rien pour toi.

Moi je vais me mettre à faire pareil tiens. Dès que quelqu'un parle de Python ou KDE (je dis n'importe quoi) : "oué mais c'est pas libre, rien nous garantie que ces technos ne violent pas de brevets logiciels".

Il est vrai que tu dis parfaitement n'importe quoi, surtout pour Python. Python, comme par exemple Caml ou Ruby, est très innovant et n'est pas une copie d'autre chose. Il est possible que Python viole des brevets, mais ce n'est certainement pas la copie de quelque chose inventée par d'autres.

C'est une façon simple et pratique de dénigrer une techno sans éléments tangibles.

Et voilà, tu te dévoiles. Tu te trompes d'adversaire, mon cher. J'admire .NET et C# qui sont pour moi l'étape logique après Java. Excepté deux ou trois conneries, C# est à mon avis strictement mieux que Java, ditto pour le framework. La techno est merveilleuse et les promesses pour la version 3 sont impressionnantes. Mais voilà, c'est une techno microsoft qui fait partie de sa stratégie actuelle et ça pose de nombreux problèmes non techniques.

Un autre exemple appliqué au monde de l'automobile (vendeur Mercedes) : "BMW c'est dangereux, rien ne vous prouve que vous allez pas vous envoyer dans le décor au prochain virage" Genre c'est un problème spécifique à BMW.

Belle comparaison débile. Et si je te parle de la classe A et du test de l'élan, tu te rends mieux compte du caractère débile de ta comparaison ? Encore une fois, tu devrais lire les commentaires des autres avant de répondre de travers avec ton cathéchisme pro-mono. J'ai passé des jours et des jours à me documenter sur le sujet, à lire des dizaines d'articles, blogs, brevets, etc. pour écrire mon article dans Linux Mag. Tu me confonds avec un trolleur de base, donc récapitulons pour ta future réponse :

1) techniquement, C# et .NET sont de très belles choses que j'admire
2) je connais le sujet

Pourquoi ce raisonnement falacieux ? Si les bibliothèques natives sont portables, il n'y a aucun problème. cf GTK. Et .NET offre même un mécanisme d'appel de code natif qui est justement portable. JNI n'est pas portable par exemple, il faut recompiler.

??? En quoi JNI n'est pas portable, c'est justement fait pour ? Et en quoi la recompilation pose un problème de portabilité ? L'avantage de .NET sur JNI c'est que la VM de .NET est plus souple que la JVM et peut donc s'interfacer plus simplement avec des bibliothèques natives. Avec JNI, on a une grosse couche d'interfaçage lourdingue, en tout cas plus lourde que celle de .NET. C'est un gros avantage, mais ce n'est pas une raison pour raconter n'importe quoi.

Je te parle de technique, pas de l'utilisation de cette technique. Le fait que la VM de .NET soit pensée pour le multi-langage est une différence fondamentale avec la JVM, même si cette fonctionnalité est peu utilisée.

A part ça, Timaniac a très bien répondu sur la portabilité : depuis quand une bibliothèque native n'est pas portable ?

Ce qui en plus ne veut pas dire qu'on peut l'implémenter librement (cf le mp3)
C'est faux.

Tu as quelques problèmes de lecture, comme toujours quand il s'agit de .NET. Je me contente ici de rappeler que standard ne veut pas dire librement implémentable, ce qui est vrai, car il existe des standards comme mp3 qu'on ne peut pas implémenter librement dans certains pays.

Jusqu'à preuve du contraire Microsoft ne détient aucun brevet sur .NET.

Le brevet sur une grande partie de l'API de .NET est en cours d'étude par le bureau des brevets américains. Pour l'instant, le brevet est rejeté, de façon non définitive. Ce qui est amusant, c'est que d'après l'expert du bureau qui a examiné la demande, celle-ci est entres autres non valide car elle prétend breveter des choses qui le sont déjà (cf http://portal.uspto.gov/external/portal/pair et saisir le numéro de demande 10/087027). Donc, une partie de l'API de .NET est couverte par des brevets (qui ne semblent pas appartenir à Microsoft). Donc tu as raison et ça ne prouve pas que .NET peut être implémenté librement...

Et jusqu'à preuve du contraire, la plupart des logiciels libres violent également potentiellement un ou plusieurs brevets logiciels.

Oui, oui, et potentiellement, par effet tunel, ton cul peut traverser ta chaise. Timaniac, tu ne sais vraiment pas argumenter. Ce n'est pas parce que quelque chose est pourri que ça justifie d'utiliser autre chose qui est tout aussi pourri...

Le problème c'est les brevets logiciels en général.

Ba oui, et ça s'applique donc à .NET.

C'est vrai que les autre participants comme Intel et HP sont des gros noobs. D'ailleur le premier n'y connaît strictement rien en langage et compilation.

Mon pauvre, dans ton évangelisme forcené tu ne comprends même pas l'ironie. Je suis tout à fait d'accord avec toi, MS ne contrôle pas complètement l'évolution de .NET, en tout cas pas la partie standardisée.

Pfiou, ça en fait des idées reçues dans un même post...

Alors dans l'ordre :

.Net est standard. Ok

C'est faux (ce n'est pas de toi, mais bon). Une petite partie de .NET est standardisée. Ce qui en plus ne veut pas dire qu'on peut l'implémenter librement (cf le mp3). Pour des détails : http://apiacoa.org/publications/vulgarisation.html#lm-java-d(...)

Mais le passage au .Net 2.0 (vers octobre-novembre chépu) en nouveau standard a causé quelques changements et effectivement on sent qu'ils ne pensent pas aux autres.

C'est sûr que comme le standard évolue par l'intermédiaire de l'ECMA et que la commission contient des gens comme Novell, MS fait ce qu'il veut et ne pense pas aux autres...

.Net (ne confondons pas avec c#, on peut imaginer tous les langages en .Net) n'est qu'un clone de Java datant d'une époque où Microsoft et Sun étaient en concurrence.

Quel raccourci saisissant et faux... Le mieux je pense est l'auto-contradiction. .NET a été pensé pour faire du multi-langage, ce qui est une différence fondamentale avec la JVM de Sun. Les mécanismes d'interfaçage de bas niveau sont fondamentalement différent entre .NET et la JVM, ce qui permet à .NET de récupérer des bibliothèques existantes beaucoup plus facilement. Les opérations prévues dans la VM de .NET sont assez différentes de celles de la JVM, elles ne sont pas prévues pour être interprétables facilement, par exemple (il faut donc un compilateur JIT pour avoir de bonnes performances). .NET possède des modes de passage de paramètres beaucoup plus riche que ceux de la JVM, ce qui facilite l'implémentation de langages comme le Pascal, par exemple, etc. Ces différences sont fondamentales et dire que .NET est un clone de Java, c'est exactement comme dire que Java est un clone de C++, c'est un raccourci totatement faux. Sans compter ce qui est prévu pour les versions suivantes de .NET, avec une forte inspiration fonctionnelle dans C#.

Il y a quelques légères différences, mais les deux ont le même esprit.

Oui, c'est le même esprit : machine virtuelle + langage orienté objet avec garbage collecting. Mais les différences sont énormes quand on y prète attention et surtout les langages phares (C# et Java) évoluent dans des directions assez différentes.

Et dans cette optique Java présente beaucoup beaucoup plus de possibilités du à son ancieneté.

Mouais, ça dépend pour quoi et sur quelle plateforme.

Il fallait vraiment des soucis avec les machines virtuelles java pour qu'on tourne autant sur .Net.

La différence fondamentale, c'est que Mono est soutenu par Novell alors que Classpath est un travail de bénévoles, avec un peu de soutien de RedHat. Mais bon, vu le succès énorme de choses comme JBoss, je pense que Java n'a pas de soucis à se faire à court terme, d'autant que Classpath sera très bientôt compatible à 100% avec java 1.4 (on peut quand même faire tourner azureus et eclipse avec classpath, par exemple). Classpath couvre actuellement 98% de l'api 1.4 (cf http://www.kaffe.org/%7Estuart/japi/htmlout/h-jdk14-classpat(...) ).

J'ai beau très bien connaître le .Net (12h de .Net par semaine, ça aide),

Encore du boulot...

Quant à la Bible, ça se lit difficilement dans un seul sens.

C'est sur qu'à l'envers, ça va tout de suite mieux.

La version de blackdown étant produite à partir du code de Sun, elle n'est pas plus libre que celle de Sun.

Le support de 1.5 par GCJ et Classpath avance très bien, ceci dit.

Euh, là c'est idiot ce que tu dis.

Si tu apprenais à lire, ça te semblerait moins idiot et ça t'éviterait de répondre à côté de la plaque.

Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs.

Oui, c'est ce que j'ai dit, c'est un argument marketing, du multi-processeur plus facile à mettre en oeuvre.

Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.

En effet et alors ? J'ai dit que ça avait un rapport ?

Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.

Tu confonds la gestion de la communication entre les processeurs et avec le chipset (contrôleur mémoire inclus), et l'intégration de cette gestion dans le processeur. AMD a depuis des années des choses intéressantes pour la communication du processeur avec l'extérieur (hyper transport et compagnie), avant ce n'était pas intégré au processeur, c'est tout.

Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.

La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.

Il y a eu du cache partagé sur les machines SMP depuis très longtemps. Les futurs multi-core d'Intel et d'AMD prévoient d'intégrer du cache partagé. Nous verrons dans le futur si les ingénieurs des entreprises cités sont aussi nuls que tu le penses ou non.

Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.

De quoi parles-tu ?

Le 64 bits grand public a en effet été introduit par AMD, mais le 64 bits existait bien avant ça (processeurs alpha, Itanium d'Intel, etc.). Le dual core est un argument marketing (très joli, il est vrai) mais en aucun cas une véritable innovation technique. Quand le cache sera partagé entre les cores, on en reparlera, pour l'instant c'est simplement du bi-processeur un peu plus facile à mettre en oeuvre qu'avant (j'ai eu un bi-pro intel (P III) et un bi-pro AMD, j'espère qu'AMD a fait des progres depuis...). Le contrôleur RAM intégré est un vaste débat. Est-ce vraiment utile, difficile à dire puisqu'on ne peut pas comparer deux solutions strictement équivalentes exceptées le contrôleur, donc pas de conclusion.

Dans l'autre sens, seul Intel est capable de fournir une vraie plateforme basse consommation avec son Centrino. Le Turion consomme assez peu (un peu plus que le pentium M), mais les chipsets ne suivent pas ce qui fait qu'un portable Turion a une autonomie beaucoup plus faible qu'un portable Pentium M à fonctionnalités comparables.

Bref.

Oui, enfin, grosse bouse, il ne faudrait tout de même pas exagérer. La grosse bouse en question propose un hyperthreadnig fort agréable en pratique. Elle a certe de nombreux défauts (consommation éléctrique délirante et ratio performances/fréquence assez faible), mais de la à dire que c'est de la merde... Par contre, c'est une voix sans issue, d'où le retour d'IBM vers l'architecture des PIII par l'intermédiaire du pentium M et de ces successeurs. Il est vrai que les PIII ressemblent aux AMD (pipeline court), mais encore une fois, dire qu'Intel suit AMD, c'est encore un peu exagéré...

Si tu as le temps, tu peux lire mon "gros" article à ce sujet. Il est un peu vieux (un an), mais il reste d'actualité : http://apiacoa.org/publications/vulgarisation.html#lm-java-d(...)

Nous sommes d'accord, il serait logique que ce qui est financé par l'argent public (ce n'est pas le seul financement de l'inria, mais c'est le plus important) soit libre d'accès. Le problème est que l'état pousse de plus en plus au contraire, en demandant de valoriser les résultats de recherche, sachant que la définition de valoriser est "faire du fric avec". Le problème est donc très politique et seules des décisions prises au niveau gouvernemental ou parlementaire pourrait changer la donne.

Il me semble que BS est propriétaire du code

Si c'est le cas, l'INRIA n'a rien a dire point final. En gros, c'est l'employeur qui est propriétaire.

Oui mais si on fait ça, on donne notre techno à Microsoft et/ou Sun qui peuvent poser un brevet dessu et nous interdir de l'utiliser !

Mais non, le delais d'un an n'est valide que si ce sont les auteurs de la publication qui brevetent.

D'après ce que j'ai compris c'est très risqué de faire quelques chose sans l'accord de transfert. Après je ne peux en dire plus (check tes mails), il faudrait vraiment que tu en discutes avec lui en privé.

Ton employeur est propriétaire de ton code, voilà. Donc si tu veux le diffuser et que tu es payé par l'inria, il te faut l'accord du "correspondant développement et relation industriel"...

Ou alors que l'auteur n'a pas encore de poste à l'Inria.
Quand il en aura un, oui, ce sera différent.

Euh... qui a payé l'auteur pendant le développement ? Autrement dit, qui est propriétaire du code ?

Tout n'est pas publié et il ne sert à rien de bréveter ça en Europe, c'est aux Etats-Unis et au Japon qu'il faut le faire. C'est pour ça que RMS me propose l'aide d'un avocat de sa connaissance.

Aux USA, il y a effectivement un délais (genre un an, je crois) entre le moment de la publication et la date limite pour déposer un brevet. Pour ce qui n'est pas publié, je suggère de la faire tout de suite pour faire chier transfert ;-)

Mais ça c'est possible quand tu as un poste de fonctionnaire, pas quand tu ne sais pas ce que tu feras l'année prochaine.
J'imagine que tu sais de quoi je parle.

C'est aussi aux fonctionnaires de ton équipe de te défendre. Mon chef de projet est prolibre, donc ça roule. Sauf erreur de ma part, Dominique Colnet n'est pas un RMS. Il me semble que les permières versions de smalleiffel n'étaient pas libres, en gros pour des raisons évoquées dans le même esprit que celles que tu mets en avant pour protéger le compilateur (innovations, etc.). Je ne connais pas Colnet et je respecte ses choix, maintenant il faut aussi faire la part des choses : transfert ne poursuit pas les équipes de l'inria de ses ardeurs à longueur de temps. Je pense que le projet a donc une part de responsabilité dans l'affaire, même si je parle dans le vide car je ne connais pas la face cachée.

Ils ont considérablement travaillé dessus aux valorisation industrielles et je sais pas s'ils se feraient avoir là dessus, faut pas non plus les prendre pour des imbéciles :-)

Non, il faut les devancer. Si tu bosses sur quelque chose de nouveau, il faut demander très rapidement, même quand c'est bien pourri, de le mettre sur gforge avec une licence libre, comme ça, dans le baba pour une valorisation par la fermeture du code.

C'est Inria Transfert qui est contre.

Il y a quelque chose qui m'échappe dans cette phrase, en tant que chargé de recherche inria. Dans ses voeux pour l'année 2005, notre président Gilles Kahn a indiqué explicitement que les chercheurs étaient associés aux prises de décision concernant les logiciels qu'ils développent, en particulier pour tout ce qui concerne la valorisation. Si le compilateur est fermé, c'est que l'auteur négocie mal avec la direction.

Quelques autres remarques en vrac.

D'abord, si l'auteur avait publié ses algorithmes "révolutionnaires" (peut être l'a-t-il fait), la protection par brevet serait impossible, au moins en France (publié = impossible à breveter).

D'autre part, si le compilateur est impossible à développer sans l'auteur, pourquoi n'est-ce pas utilisé comme argument de négociation, de la forme : libre ou j'arrête de développer. Ou mieux : libre, sinon le jour ou je me casse, personne ne pourra rien en faire. Ou encore : libre sinon vous pourrez toujours essayer de vendre des licences quand personne ne sera capable de faire le support.

A part ça, je livre ma super astuce personnelle pour distribuer mes créations sous licences libres : j'utilise une bibliothèque avec une licence contaminante, par exemple la GPL. Un de mes anciens thésards a ainsi développé tout un code de réseaux de neurones basé sur la GSL qui est GPL (pas LGPL). Moralité, l'Inria peut soit ne pas le diffuser (développement interne) soit le diffuser en GPL. Gnark, gnark ;-) Autre astuce : négocier dès le début d'un développement logiciel en disant que l'outil est sympa sans plus. On obtient ainsi le droit de distribuer ça dans une licence libre et c'est plié.

Bien entendu, je parle ici en tant que Boubou, sans engager mon autre moi (Fabrice Rossi) CR à l'Inria.

Tu as parfaitement raison, mais l'hébergement de linuxfr est mutualisé, donc l'espace de stockage pourrait très bien être partagé (d'où l'intérêt d'un NAS). On peut aussi configurer le NAS avec beaucoup moins de stockage (par exemple 360 Go pour 1800 ¤). D'autre part, si le disque pèse 20 Go, le RAID en contient 60, pas 20...

Vu le prix délirant, n'est-il pas possible d'en profiter pour changer RAID complet, par exemple pour un petit NAS de grande capacité ? On trouve des NAS avec un RAID 4 de 750Go pour 2250 ¤ (cf http://www.yatoo.info/catalogue/product_info.php?cPath=1&(...) ). Je sais bien que c'est beaucoup plus cher, mais ça offre aussi beaucoup plus.

Pour le 1.5, c'est environ 84%. On trouve les couvertures sur le site d'un développeur de kaffé : http://www.kaffe.org/%7Estuart/japi/(...) On se rend compte que le point bloquant reste essentiellement swing. Il y a quelques soucis avec corba et le son, mais en ajoutant d'autres bibliothèques, on couvre presque tout. L'énorme défaut des initiatives Java libre est qu'elles ne disposent pas d'un point d'accès unique et d'un projet centralisateur, au contraire de Mono. Mono n'est pas plus avancé que les outils Java open source, il l'est même moins en terme de compatibilité avec les bibliothèques de MS (n'oublions pas qu'en ajoutant à Java de base les extensions entreprises, on obtient une api monstreuse dont la partie entreprise est entièrement couverte par du libre, donc le pourcentage de couverture grimpe énormément), mais il est centralisé et bien organisé...

Cette différence n'existe pas. Si tu développes en Java avec Eclipse et comme cible classpath+gcj (par exemple), ton application ne tournera qu'avec du 100% libre, c'est exactement la même chose que pour Mono. Par contre, si tu récupères une application C#/.NET développée sous windows et utilisant à fond les WinForms, elle ne marchera pas plus qu'une application Swing utilisant les composants manquants de cette bibliothèque dans classpath.

A titre d'information, plus de 92 % de l'API du JDK 1.4 est implémentée par Classpath. Les extensions J2EE 1.4 sont intégralement implémentées par divers projets open source comme JBoss ou Jonas.

Moralité, la situation en pratique est plus ou moins la même pour Mono et Classpath+gcj. Par contre, du point de vue légal, ah, ah, ah...

Je crois surtout que Beagle est implémenté en C#, ce qui pose des problèmes graves de licences, brevets, etc. cf mon merveilleux papier de linux mag, maintenant en ligne http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf(...)

Timaniac, je ne répondrai pas à tes trolls.

Oui, surtout que Michou, c'est un monsieur.