"La France est dans une impasse idéologico-économico-politico-sociale"
Impasse ? On est en crise perpétuelle depuis 20 ans, selon les politiques. Selon certains économistes, il n'y a pas de crise, c'est simplement un niveau de croissance normal (+1%) pour un pays très bien équipé et qui est sorti depuis longtemps de la reconstruction d'après guerre.
Donc, en gros, la croissance faible est normale. Mais les politiques ne veulent pas le croire car, 1% ne permet pas de créer assez d'emplois pour combler le chômage. Il faudrait accepter qu'il n'y a pas de travail pour tout le monde, ce qui est inconcevable pour l'instant.
Les langages construits artificiellement essayent en général de virer toutes ambiguïtés. L'un est très simple à parser pour un ordinateur : https://en.wikipedia.org/wiki/Lojban
Je me demandais si il était possible de traduire les textes de loi dans cette langue précise (de façon semi automatique par exemple), puis de faire des raisonnements dessus.
Les textes juridiques ne sont pas si précis que ça, la signification de certain mots change selon les lois ("en tant que tel", "seulement"), l'application strict ou non d'une liste d'exception, par rapport à un principe général applicable … ou non, etc…
A l'extreme, selon ta définition, une ALU c'est un CPU.
Non, car il n'y a pas de gestion des instructions, par exemple.
qui sait juste calculer "f(x) = 4*x" et "g(x) = 5*x" avec un jeu d'instructions qui comporte deux instructions "f" "g".
Si tu compiles un code C, ayant
int f(int x) {return 4*x;}; int g(int x){ return 5*x;}
Cela aurait un sens que cela soit le résultat après simplification. Cela ne serait plus un cpu, c'est vrai. Sauf que ce n'est pas un code C qui fait quelques choses, typiquement, il n'y a aucune IO.
Je dis qu'on peut faire un circuit spécifique qui fait du décodage MPEG4 qui n'est pas un CPU.
On peut toujours tout faire en hard, c'est moi qui avait pris un exemple. En plus, le tien est un décodeur, qui est infiniment plus simple qu'un codeur.
C'est une évidence.
Non justement. Si tu pars sur un array de cpu vliw comme pattern de base, et tu compiles des blocs pour miner du bitcoin, ton code peut devenir une centaine de core avec des instructions sha cablé, qui seront bien plus rapide qu'un x86.
Les performances des CPUs implémentés dans les FPGA sont très très faibles.
Oui si tu pars de cpu monocore simple, mais commence avec du multicore multithreadé en vliw, ce n'est pas automatique du tout.
Si on sait faire ça, c'est super impressionant ! Je serais intéressé si tu as des noms de logiciels / des tutoriels ou des papiers.
Je ne pense pas que l'on a déjà fait. C'était ma proposition à la question du forum :)
On peut imaginer faire une machine virtuelle pour GCC, et générer le ou les cpu a partir d'un template de cpu et de ce code objet. C'est l'idée.
On est sur (= c'est démontré) qu'un automate d'états fini n'est pas Turing complet.
Oui mais personne n'utilise une FSM toute seul, c'est pour ça que j'ai préciser + opérateur et comparateur.
Aujourd'hui c'est quand même plus complexe.
Tu mélanges la définition d'un cpu (== vue de l'extérieur) et son architecture.
C'est pour ça que c'est une mauvaise idée de faire un CPU soi-même et de le mettre dans un FPGA
Oui, c'est compliqué et surement lent, mais cela ne veut pas dire que ça l'est à coup sûr.
Je crois qu'on s'entend pas sur les définition de CPU. Et de "core" d'ailleurs. Je vois pas quelle définition tu leur donne.
Un core est un bloc hardware. Un cpu, c'est une boite noire dans lequel plusieurs bus rentre et sorte, et qui est capable d’exécuter des instruction. On peut imaginer que ces instructions soient dans une ROM.
Note que même comme ça un encodeur MPEG4 impémenté dans un FPGA, c'est pas un CPU.
Non!! Tu racontes n'importe quoi. L'encodeur MP4 embarqué dans l'omap4 de TI, c'est 2 ARM M0 ou 4, qui pilote 2 DSP.
Et on peut implémenter plus ou moins d'opérations en matériel.
J'ai du oublier de dire, que c'est absolument n'importe quoi de croire que faire des va et vient avec le x86 pouvait avoir un intérêt. Je considère que tout est fait dans la carte d'extension, cela sera toujours trop lent sinon.
Je considère gcc uniquement comme un code C. Donc, le génerateur de bitstream peut déduire facilement les ensembles d'instructions les plus utiles et les fusionner ou dupliqué pour créer un CPU de fpga ultra rapide pour gcc. Il n'a pas connaissance de l'AST ou autre. Si c'est le cas, c'est que tu fais un design "custom" à la main, ce qui est un boulot délirant.
Je ne sais pas trop ou tu veux en venir. J'ai l'impression que tu es calé en logique/math, mais pas franchement en design hardware. La différence que tu fais sur la machine de Turing/machine d'état est artificiel.
Évidamment la machine d'état n'est pas seul, il faut rajouter des comparateurs et des opérateurs. C'est aussi de cette façon qu'est conçu un cpu. Puisqu'un cpu est un core.
Tout dépend de ce qu'on appelle un CPU. Un "CPU optimisé à mort", ça devient plus un CPU ça devient un circuit dédié à une tache spécifique.
Oui, si le code assembleur est gravé dans le marbre. Pas forcément, si la mémoire est modifiable. La structure d'un cpu est assez simple : registre, mémoire, operateurs, et instruction.
Un GPU n'est pas un CPU.
De plus, en plus.
Un encodeur MPEG4 n'est pas un CPU non plus.
Un encodeur MPEG4 est souvent composé de plusieurs DSP qui sont des cpus.
Un CPU c'est Turing complet, un circuit dédié pas forcément.
Oui mais ton circuit dédié peut être composé de cpu.
Ici on voudrait transformer GCC (le code source de GCC) en un circuit dédié à la compilation.
Oui, et c'est parfaitement possible, mais ce n'est pas garanti d'être rapide.
On voit bien que (i) CPU + assembleur de GCC et (ii) circuit à une instruction qui fait de la compilation, ça forme les deux extrémités d'un continuum.
J'imagines que tu pars avec une solution simple genre gros FPGA relier à une grosse mémoire, dans un slot pci express.
Tu veux que cette carte accélère gcc, histoire de prendre un exemple précis. Tu dis que synthétiser un cpu dans un fpga n'est pas performant dans l'absolu. C'est une évidence. Mais cela revient pourtant très exactement à la synthèse direct vers un bitstream. Un core, c'est en général une grosse machine d'état avec quelques opérateur. Un cpu c'est exactement ça, seulement la machine d'état est encodé dans une mémoire sous forme d'assembleur.
Donc, tu as une dualité core/cpu. Compiler directement du C est complexe (certain le font déjà cf synfora pico c), le principal problème est la faible sémantique de la mémoire qui oblige à avoir une grosse mémoire adressable (type DRAM) ce qui ne rentre pas dans un FPGA seul.
Une fois que tu as un cpu, tu peux l'optimiser à mort comme tu le veux en fonction de la tâche à faire. C'est cette optimisation qui pourra te faire gagner du temps (VLIW, multicore,…) par rapport à l'execution sur x86.
L'optimiseur de cpu dispose du code C à compiler, il peut choisir les meilleurs options.
(je suis même pas certain que ce soit théoriquement faisable).
Si tu as un FPGA + une DRAM, si forcément. Il suffit d'avoir un modèle de cpu qui est mis dans le FPGA et le compilo cible l'assembleur du cpu.
Ensuite, tu peux imaginer l'élimination des opérateurs inutiles, ou la création de la combinaison d'opérateur. Tu peux avoir un modèle de cpu très complexe que tu simplifies pour ton code assembleur.
ocsgen permet de faire des GUI vaguement en ocaml pour le web, mais ce n'est pas du vrai ocaml, et il n'y aucune abstraction des techno web (il faut tout connaitre : DOM, HTML5, JS, widget JS,…).
"Parcontre, GEGL gère bien les grosses images avec tuilage, swap sur fichier, etc."
Tu veux dire qu'un traitement ne se fait pas entièrement sur l'image avant de passer au suivant, mais entièrement sur une tuile avant de passer à l'autre ? Si la tuile reste en cache, cela peut être une situation intermédiaire très efficace.
Est-ce que gegl est capable de gérer aussi les "preview" cad appliquer les filtres sur une réduction de l'image pour avoir le résultat plus vite à l'écran, sans faire le traitement entier puis la réduction ? C'est important pour avoir un feedback rapidement et faire des ajustements.
Dans ma boite de soft proprio, le support est efficace en gérant les questions fréquemment posé. En cas de bug, c'est remonté directement aux dev. Si il n'y a pas de contournement possible et que l'on ne peut pas attendre la sorti suivante, on sort un patch en urgence.
Payer chère, permet aussi d'avoir ce genre de service.
Je rappelle que Sun avait racheter staroffice, car acheter cette boite coutait moins chère que des payer les 10 000 licences word dont ils avaient besoin.
C'est le même principe ici, vu l'échelle de l'état, c'est évident qu'un grand nombre de logiciel couterait beaucoup moins chère si il était développé en open source (en interne ou pas).
Par exemple, combien représente de salaire d’ingénieurs, le cout annuels des licences Office ? A moyen terme n'est-ce pas plus efficace d'orienter le logiciel vers ses besoins ?
Si, car c'était ouvert, et ils ont mis des barrières physiques. Ce n'était sans doute pas officiellement ouvert, mais maintenant ils vont à rebours de l'histoire.
J'ai lu un peu vite, mais la boite qui fait des site web, elle génère bien des graphes à la volé, donc il y a bien un moyen de les voir sous forme de data et non de code.
J'imagine que gegl ne fait pas d'optimisation, il n'est pas capable d'éviter la création d'un buffer lorsque l'on passe d'un noeud d'un graph à un autre ? Mais est-ce qu'il pourra le faire à terme ?
Une correction gamma suivi d'une augmentation de luminosité est une simple opération à faire sur chaque pixel, elles peuvent être fusionné, et il n'y a pas besoin de passer par un buffer intermédiaire.
Je pause cette question, car pour avoir utiliser darktable, qui ne fait pas de destructif non plus, il arrive vite à manger toute la mémoire, avec seulement quelques opérations.
Un brevet, je vois surtout cela comme un champ de mines pour les concurrents. On peut mettre les champs de mines en commun pour en faire des encore plus gros, ou pour menacer un concurrent plus petit.
Tu mélanges droit d'auteur qui sont passé de 50 à 70 voir 90 ans après la mort de l'auteur, et le brevet qui dure heureusement que 20 ans.
Mais dans l'ensemble, tu as raison. Le problème est aussi que les offices n'auront jamais les moyens de vérifier le "prior art". Actuellement, ils ont une demi-journée de vérification par brevet. Les seuls bases de données à leur disposition, sont les brevets déjà déposés. Pour eux, le "prior art" est constitué, de fait, uniquement des brevets déjà déposés !
[^] # Re: Le futur c'était mieux avant
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Les avocats à la poubelle. Évalué à 10.
Impasse ? On est en crise perpétuelle depuis 20 ans, selon les politiques. Selon certains économistes, il n'y a pas de crise, c'est simplement un niveau de croissance normal (+1%) pour un pays très bien équipé et qui est sorti depuis longtemps de la reconstruction d'après guerre.
Donc, en gros, la croissance faible est normale. Mais les politiques ne veulent pas le croire car, 1% ne permet pas de créer assez d'emplois pour combler le chômage. Il faudrait accepter qu'il n'y a pas de travail pour tout le monde, ce qui est inconcevable pour l'instant.
"La première sécurité est la liberté"
[^] # Re: Autant les juristes...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Les avocats à la poubelle. Évalué à 2.
Les langages construits artificiellement essayent en général de virer toutes ambiguïtés. L'un est très simple à parser pour un ordinateur : https://en.wikipedia.org/wiki/Lojban
Je me demandais si il était possible de traduire les textes de loi dans cette langue précise (de façon semi automatique par exemple), puis de faire des raisonnements dessus.
Les textes juridiques ne sont pas si précis que ça, la signification de certain mots change selon les lois ("en tant que tel", "seulement"), l'application strict ou non d'une liste d'exception, par rapport à un principe général applicable … ou non, etc…
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 4.
Non, car il n'y a pas de gestion des instructions, par exemple.
Si tu compiles un code C, ayant
int f(int x) {return 4*x;}; int g(int x){ return 5*x;}
Cela aurait un sens que cela soit le résultat après simplification. Cela ne serait plus un cpu, c'est vrai. Sauf que ce n'est pas un code C qui fait quelques choses, typiquement, il n'y a aucune IO.
On peut toujours tout faire en hard, c'est moi qui avait pris un exemple. En plus, le tien est un décodeur, qui est infiniment plus simple qu'un codeur.
Non justement. Si tu pars sur un array de cpu vliw comme pattern de base, et tu compiles des blocs pour miner du bitcoin, ton code peut devenir une centaine de core avec des instructions sha cablé, qui seront bien plus rapide qu'un x86.
Oui si tu pars de cpu monocore simple, mais commence avec du multicore multithreadé en vliw, ce n'est pas automatique du tout.
Je ne pense pas que l'on a déjà fait. C'était ma proposition à la question du forum :)
On peut imaginer faire une machine virtuelle pour GCC, et générer le ou les cpu a partir d'un template de cpu et de ce code objet. C'est l'idée.
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 3.
Oui mais personne n'utilise une FSM toute seul, c'est pour ça que j'ai préciser + opérateur et comparateur.
Tu mélanges la définition d'un cpu (== vue de l'extérieur) et son architecture.
Oui, c'est compliqué et surement lent, mais cela ne veut pas dire que ça l'est à coup sûr.
Un core est un bloc hardware. Un cpu, c'est une boite noire dans lequel plusieurs bus rentre et sorte, et qui est capable d’exécuter des instruction. On peut imaginer que ces instructions soient dans une ROM.
Non!! Tu racontes n'importe quoi. L'encodeur MP4 embarqué dans l'omap4 de TI, c'est 2 ARM M0 ou 4, qui pilote 2 DSP.
J'ai du oublier de dire, que c'est absolument n'importe quoi de croire que faire des va et vient avec le x86 pouvait avoir un intérêt. Je considère que tout est fait dans la carte d'extension, cela sera toujours trop lent sinon.
Je considère gcc uniquement comme un code C. Donc, le génerateur de bitstream peut déduire facilement les ensembles d'instructions les plus utiles et les fusionner ou dupliqué pour créer un CPU de fpga ultra rapide pour gcc. Il n'a pas connaissance de l'AST ou autre. Si c'est le cas, c'est que tu fais un design "custom" à la main, ce qui est un boulot délirant.
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 2. Dernière modification le 09 juillet 2015 à 14:03.
Je ne sais pas trop ou tu veux en venir. J'ai l'impression que tu es calé en logique/math, mais pas franchement en design hardware. La différence que tu fais sur la machine de Turing/machine d'état est artificiel.
Évidamment la machine d'état n'est pas seul, il faut rajouter des comparateurs et des opérateurs. C'est aussi de cette façon qu'est conçu un cpu. Puisqu'un cpu est un core.
Oui, si le code assembleur est gravé dans le marbre. Pas forcément, si la mémoire est modifiable. La structure d'un cpu est assez simple : registre, mémoire, operateurs, et instruction.
De plus, en plus.
Un encodeur MPEG4 est souvent composé de plusieurs DSP qui sont des cpus.
Oui mais ton circuit dédié peut être composé de cpu.
Oui, et c'est parfaitement possible, mais ce n'est pas garanti d'être rapide.
Ou veux-tu en venir ?
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 3.
J'imagines que tu pars avec une solution simple genre gros FPGA relier à une grosse mémoire, dans un slot pci express.
Tu veux que cette carte accélère gcc, histoire de prendre un exemple précis. Tu dis que synthétiser un cpu dans un fpga n'est pas performant dans l'absolu. C'est une évidence. Mais cela revient pourtant très exactement à la synthèse direct vers un bitstream. Un core, c'est en général une grosse machine d'état avec quelques opérateur. Un cpu c'est exactement ça, seulement la machine d'état est encodé dans une mémoire sous forme d'assembleur.
Donc, tu as une dualité core/cpu. Compiler directement du C est complexe (certain le font déjà cf synfora pico c), le principal problème est la faible sémantique de la mémoire qui oblige à avoir une grosse mémoire adressable (type DRAM) ce qui ne rentre pas dans un FPGA seul.
Une fois que tu as un cpu, tu peux l'optimiser à mort comme tu le veux en fonction de la tâche à faire. C'est cette optimisation qui pourra te faire gagner du temps (VLIW, multicore,…) par rapport à l'execution sur x86.
L'optimiseur de cpu dispose du code C à compiler, il peut choisir les meilleurs options.
"La première sécurité est la liberté"
# modèle de risque ?
Posté par Nicolas Boulay (site web personnel) . En réponse au message Nano-ordinateur "protégé". Évalué à 4.
C'est difficile de te répondre sans un modèle de risque.
Si ton automatisme est un flicage des ouvriers, le risque n'est pas le même que si il s'agit d'une gestion de clim.
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 4.
Si tu as un FPGA + une DRAM, si forcément. Il suffit d'avoir un modèle de cpu qui est mis dans le FPGA et le compilo cible l'assembleur du cpu.
Ensuite, tu peux imaginer l'élimination des opérateurs inutiles, ou la création de la combinaison d'opérateur. Tu peux avoir un modèle de cpu très complexe que tu simplifies pour ton code assembleur.
"La première sécurité est la liberté"
# GUI ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de Stog en version 0.15. Évalué à 2.
Est-ce qu'il y a un moyen de faire des gui avec ?
ocsgen permet de faire des GUI vaguement en ocaml pour le web, mais ce n'est pas du vrai ocaml, et il n'y aucune abstraction des techno web (il faut tout connaitre : DOM, HTML5, JS, widget JS,…).
"La première sécurité est la liberté"
[^] # Re: et pourtant...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nous les intellectuels autoproclamés du numérique. Évalué à 4.
Et ST, et Infineon, et Thales, et Airbus, et Alcatel ?
"La première sécurité est la liberté"
[^] # Re: perf ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 2. Dernière modification le 26 juin 2015 à 14:27.
Tu veux dire qu'un traitement ne se fait pas entièrement sur l'image avant de passer au suivant, mais entièrement sur une tuile avant de passer à l'autre ? Si la tuile reste en cache, cela peut être une situation intermédiaire très efficace.
Est-ce que gegl est capable de gérer aussi les "preview" cad appliquer les filtres sur une réduction de l'image pour avoir le résultat plus vite à l'écran, sans faire le traitement entier puis la réduction ? C'est important pour avoir un feedback rapidement et faire des ajustements.
"La première sécurité est la liberté"
[^] # Re: Bouleversifiant
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nous les intellectuels autoproclamés du numérique. Évalué à 4.
Dans ma boite de soft proprio, le support est efficace en gérant les questions fréquemment posé. En cas de bug, c'est remonté directement aux dev. Si il n'y a pas de contournement possible et que l'on ne peut pas attendre la sorti suivante, on sort un patch en urgence.
Payer chère, permet aussi d'avoir ce genre de service.
"La première sécurité est la liberté"
# et pourtant...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nous les intellectuels autoproclamés du numérique. Évalué à 10.
Je rappelle que Sun avait racheter staroffice, car acheter cette boite coutait moins chère que des payer les 10 000 licences word dont ils avaient besoin.
C'est le même principe ici, vu l'échelle de l'état, c'est évident qu'un grand nombre de logiciel couterait beaucoup moins chère si il était développé en open source (en interne ou pas).
Par exemple, combien représente de salaire d’ingénieurs, le cout annuels des licences Office ? A moyen terme n'est-ce pas plus efficace d'orienter le logiciel vers ses besoins ?
"La première sécurité est la liberté"
[^] # Re: oui et non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'État français retourne sa veste sur l'Open Data dans les transports. Évalué à 4.
L'amendement rend l'open data facultative si il y a une "convention". Donc, les obligations disparaissent avec les bons mots magiques.
"La première sécurité est la liberté"
[^] # Re: Raildar
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'État français retourne sa veste sur l'Open Data dans les transports. Évalué à 3.
Si, car c'était ouvert, et ils ont mis des barrières physiques. Ce n'était sans doute pas officiellement ouvert, mais maintenant ils vont à rebours de l'histoire.
"La première sécurité est la liberté"
# un autre article
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'État français retourne sa veste sur l'Open Data dans les transports. Évalué à 5.
http://www.nextinpact.com/news/95504-le-gouvernement-pret-a-saper-open-data-sur-donnees-transport.htm
"La première sécurité est la liberté"
# nouveauté ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de Haxe 3.2.0. Évalué à 3.
Je n'ai pas compris l'apport de haxe par rapport à d'autre langage voir même C++.
C'est un langage objet de plus ? Les macro ont l'air de sortir de l'ordinaire.
"La première sécurité est la liberté"
[^] # Re: perf ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 2.
J'ai lu un peu vite, mais la boite qui fait des site web, elle génère bien des graphes à la volé, donc il y a bien un moyen de les voir sous forme de data et non de code.
"La première sécurité est la liberté"
[^] # Re: perf ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 2.
Disons que je serais capable de faire ce genre d'optim, mais pas en C. Cela serait trop douloureux.
Peut-être qu'il est possible de faire une "optimisation" du graph qui fusionnerait des opérations, mais de façon externe à la lib ?
"La première sécurité est la liberté"
# perf ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 7.
J'imagine que gegl ne fait pas d'optimisation, il n'est pas capable d'éviter la création d'un buffer lorsque l'on passe d'un noeud d'un graph à un autre ? Mais est-ce qu'il pourra le faire à terme ?
Une correction gamma suivi d'une augmentation de luminosité est une simple opération à faire sur chaque pixel, elles peuvent être fusionné, et il n'y a pas besoin de passer par un buffer intermédiaire.
Je pause cette question, car pour avoir utiliser darktable, qui ne fait pas de destructif non plus, il arrive vite à manger toute la mémoire, avec seulement quelques opérations.
"La première sécurité est la liberté"
[^] # Re: Brevets en général
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 3.
Comment faire sans toucher le principe du système ?
"La première sécurité est la liberté"
[^] # Re: je suis un peu perdu
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 3.
Un brevet, je vois surtout cela comme un champ de mines pour les concurrents. On peut mettre les champs de mines en commun pour en faire des encore plus gros, ou pour menacer un concurrent plus petit.
"La première sécurité est la liberté"
[^] # Re: je suis un peu perdu
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 6.
Tu mélanges droit d'auteur qui sont passé de 50 à 70 voir 90 ans après la mort de l'auteur, et le brevet qui dure heureusement que 20 ans.
Mais dans l'ensemble, tu as raison. Le problème est aussi que les offices n'auront jamais les moyens de vérifier le "prior art". Actuellement, ils ont une demi-journée de vérification par brevet. Les seuls bases de données à leur disposition, sont les brevets déjà déposés. Pour eux, le "prior art" est constitué, de fait, uniquement des brevets déjà déposés !
"La première sécurité est la liberté"
[^] # Re: Brevets en général
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 4.
Tu n'a jamais entendu parler des patents trolls ?
"La première sécurité est la liberté"
[^] # Re: Brevets en général
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et dire qu'avec le brevet logiciel on est loin de toucher le fond.. Évalué à 4.
Réduire les équations, aux équations de la physique, est du grand n'importe quoi.
"La première sécurité est la liberté"