non, tu confonds avec RSS, qui est de Netscape, à l'origine. RDF est un format standardisé par le w3c, et n'a rien à voir avec RSS, si ce n'est que la version 1.0 de RSS utilise RDF pour structurer ses données (alors que les autres versions de RSS, 0.9x et 2.0 utilise le format... rss).
pour taper de la documentation, tu n'as pas besoin d'un éditeur évolué. Voir même pas d'éditeur du tout. la preuve, (wikipedia) une interface web suffit pour taper de la documentation.
Maintenant, pour taper du code source, c'est *vachement* plus agréable d'avoir la coloration syntaxique, la completion de code auto etc... Tout ce que tu ne peux pas faire dans une interface web.
Autant l'ASFI et l'arroseur sont vraiment mal choisi (le wiif ce n'est pas que pour l'internet comme on l'a fait remarqué plus haute, et que, bon, arroseur...), autant je trouve que ce yves grandmontagne, l'auteur de la news sur silicon.fr, va un peut trop loin en disant que c'est une "perle" de dire "message multimedia" pour MMS... On lui rappel ce que veut dire l'acronyme MMS ? Et un spam, c'est bien un message non sollicité non ?
Ah lala, ces pseudos journalistes qui veulent se la peter toujours un peu plus... C'est si facile de taper sur quelqu'un ou sur quelque chose. Ça critique, ça critique, mais il propose quoi lui en remplacement ?
comme le dit un autre commentaire, on pouvait avoir le SVG dans mozilla ou firefox, mais il fallait l'activer *à la compilation*.
Ce qu'il y a de nouveau donc, c'est que
- c'est compilé par défaut (il faut juste l'activer dans les preferences du navigateur)
- et puis surtout, y a de moins en moins de bug dans l'implementation, et s'améliore de semaines en semaines. D'ailleurs, il y a quelques mois, il fallait avoir beaucoup de chance pour que *tout* les exemples SVG de croczilla (http://www.croczilla.com/svg/)(...) tournent correctement. Maintenant il n'y a plus vraiment de problèmes.
Et pour ton information, les patchs, tu les trouveras sur le premier lien de la news.
Si il fourni des patchs, c'est qu'ils sont un minimum utilisable je pense. Rien n'empeche aux devs de khtml de jeter un coup d'oeil dans les patchs pour avoir une idée de comment david hyatt à résolu les problèmes.
Peut etre même bien que certains patchs concernent des fichiers qui n'ont pas été modifiés dans tous les sens par rapport au tronc de khtml.
Mais ça surement que les dev de khtml, de par leur mécontentement, ne vont même pas chercher à savoir si ils peuvent les appliquer ou pas. je me demande bien si ils ont vraiment jeté un oeil sur ces patchs, et si ils sont pas de mauvaise fois.
non. IE, par le fait d'inclure la chaine "mozilla" dans son user agent, indique qu'il se fait passer pour Mozilla, où plutot pour netscape à l'origine. (en fait, c'est pour emmerder le monde, et tirer la langue à netscape)
Mozilla = un nom inventé par les fondateurs de Netscape, et signifie Mosaic Killer (killer = gozilla), Mosaic étant l'un des touts premiers (le premier meme il me semble) navigateur web graphique. (souvenir souvenir...)
Le moteur de IE, quant à lui, est dérivé de celui de Mosaic (voir les infos de copyright dans la boite "à propos" de IE).
La norme CSS dit explicitement que toute instruction ou selecteur non conforme à la norme doit être ignorée par les navigateurs.
Cela va donc dire, si il y a une erreur dans le fichier CSS : l'ignorer. Ce que teste Acid2...
Il est même dit dans la norme CSS, que tout navigateur peut supporter *en plus* des styles qui ne sont pas dans la norme. Mais pour cela, il faut prefixer leur nom par "-foo-" où foo désigne le navigateur. Ex dans Mozilla : -moz-border-radius.
les erreurs pointés par le validateur, sont des erreurs que les développeurs du test ont [b]volontairement[/b] introduits ! (voir les commentaires dans les sources)
Ceci pour tester que le navigateur n'interprete pas des choses qui ne devrait pas l'être.
Exemple, pour la première erreur, qui est située sur cette ligne
[class=second two] { background: red; } /* this should be ignored (invalid selector -- grammar says it only accepts IDENTs or STRINGs) */
ce que XUL a de révolutionnaire, c'est que, en premier lieu, ça offre une interface utilisateur beaucoup plus riche que du HTML, et que l'on peut créer trés facilement.
Donc une première utilisation basique de XUL serait : je continue de réaliser mes applis web comme d'habitude, je remplace juste HTML par XUL. (ton histoire d'utilisation d'HTTP, ou plutôt de xmlHTTPRequest tu voulais dire je pense, parce que bon, HTTP, tu peux pas t'en passer :-p, enfin bon, ton histoire de xmlHTTPRequest n'a pas lieu d'être dans ce cas )
Une utilisation plus intelligente, c'est je remplace HTML par XUL, mais j'utilise aussi des services web (via xmlHttpRequest). Ça permet plein de choses
- pas de rechargement de l'interface -> economie bande passante, et charge moins importante du serveur (il n'a pas à tout regenerer l'interface, donc éventuellement à faire des dizaines de requetes pour cela)
- séparation en couche : d'un coté l'UI, et de l'autre des services webs. Lesdit services pouvant non seulement être appelés par l'UI, mais également par toutes autres applications (web, desktop..) bref, -> capitalisation des développements.
- ps de rechargement -> interface plus reactive, plus dynamique, tout ce qui est lié à l'interface est fait coté client -> ergonomie améliorée
En tout cas, je ne vois pas en quoi cette tendance à utiliser xmlHTTPRequest a de mauvais. Elle permet de faire des choses vraiment plus simple et plus efficace dans les applications web (pour les *sites* web, c'est autre chose), autant pour le développeur que pour l'utilisateur.
les programmes non-libres sont dangereux pour vous et votre communauté
"Et si vous continuez à les utiliser, vous et votre famille surporteront la colère du guru RMS sur 5 générations, vous serez gangréné par le cancer incurable GPL, vous irez tous en enfer au milieu de pinguoins mangeur d'homme dréssés par Linus, par -50 °C (oui l'enfer ça peut être trés froid il parait), et un déluge d'instructions assembleurs s'abattra sur vous pendant 10 ans si dans 1 mois vous n'avez pas voté OUI aux logiciels libres."
->[] (faut vite que j'aille effacer cette partition windows qui ne me sert plus à grand chose...)
car il y a des repertoires où tu ne veux pas voir tout les fichiers cachés, et d'autres si (par exemple toujours voir le .htaccess des sites web que l'on developpe)
Et puis moi, j'aime bien voir ce qu'il y a réèllement dans mes répertoires. Sauf mon home car c'est vrai, plus çca va, plus ça devient vraiment le bordel.
oui et non.
C'est pas le XUL qui permet de faire ça (XUL, c'est le langage d'interface graphique). Mais par contre tu as une API disponible pour tout ce qui est web service (SOAP, XML-RPC, ou encore le fameux xmlhttprequest):
Et encore, tu n'as pas regardé du coté de Gecko. Pour développer une appli Mozilla, il faut connaitre : XML en général, XUL, XBL, CSS, XPCOM, Ecmascript, DOM, RDF, le format de package XPI... Et d'autres si on veut aller plus loin (C++, SVG, XSL, SOAP, XML-RPC, XForms, MathML etc..)
Heureusement, y a déjà un site pour ne pas s'y perdre dans tout ça ;-)
Autant je trouve que le XUL est vraiment prométeur
Prometteur ? tu es sur ? pour moi, prometteur, cela veut dire que la techno n'est pas encore disponible. Or ça fait déjà quelques années qu'on peut faire du XUL...
je me demande s'il compte en améliorer la vitesse ???
Oui bien sûr. Mais ce n'est pas XUL qui est en cause. C'est gecko, le moteur d'affichage de Mozilla/Firefox/Xulrunner, qui sait afficher tout type de fichier XML (XUL, xml qcq, XHTML, MathML, SVG ...) avec des CSS.
Et dans sa version 1.8, qui devait être utilisé par Mozilla 1.8, gecko est encore plus performant. Il faudra attendre Firefox 1.1 pour s'en rendre compte.
XulRunner ne permet pas d'aller plus vite que Firefox : ils utilisent le même moteur Gecko. Par contre, si plusieurs applis utilisent XulRunner en même temps, on va avoir des améliorations interressantes coté consommation mémoire puisque les libs de Gecko ne seront instanciée qu'une seule fois en mémoire.
Pour cela XULRunner propose de nombreux services tels que le support réseau, l'affichage HTML/CSS avec Gecko, la cryptographie ou encore la manipulation de XML.
En fait, XulRunner contient tout ce que contient Firefox et Thunderbird (tout les composants XPCOM et Gecko), sans l'interface de ces produits ;-)
j'apprends juste que Firefox sera encore plus lent
Qu'en sait -tu ? tu as une boule de crystal ? C'est pas un troll que tu as lancé, ce sont des suppositions non vérifiées.
Si les dev de Gecko ont choisi d'utiliser Cairo pour tout le reste de l'affichage, c'est certainement qu'ils ont étudié un minimum la lib et qu'ils savent donc qu'il y a moyen d'optimiser, que le cas de Cairo est loin d'être catastrophique.
Maintenant, si tu connais une alternative au moins aussi puissante, plus rapide et sous licence MPL/LGPL, contacte les. (mais te fatigue pas, ils ont surement déjà chercher longtemps)
Bref, ça sert à rien de tenter de troller là où il n'y a pas de troll.
si, c'est impossible vu le flux de demande. À moins de passer 10 ans à valider une demande de brevet, ce qui serait n'importe quoi.
Dans la mesure où un système n'est pas capable d'absorber ses flux en entrée, il faut changer le système, le modifier.
Le seul moyen actuel pour les organismes de brevet d'absorber le flux, c'est de diminuer les verifications. Ce n'est pas la bonne solution. Si maintenant la legislation dit, ne pas s'occuper de tel ou tel type de demande de brevet, ils ne seront donc pas obliger de traiter ces types de demandes, et pourront faire les verifications qui s'imposent sur les autres.
Si elles acceptent toutefois de traiter les types de brevets non permis, c'est aussi un problème car finalement actuellement rien ne les empeche (et traitent donc mal les bonnes demandes de brevets). Là encore, si une legislation les mettaient à l'amende à chaque dérive, tout se passerait certainement mieux.
Mais cela necessite là encore de changer la legislation. C'est donc bien la législation qu'il faut changer. pas changer les organismes de brevets (les nouveaux feraient exactement les mêmes betises si la legislation leur permet).
C'est pas la peine de créer de la nouvelle législation, il suffit de respecter celle qui est déjà en place.
Oui mais ça, c'est la théorie. En pratique, c'est impossible à faire car Il y a trop de vérifications à faire, trop de demande de brevets, trop de brevets déposés.
Comme c'est impossible, cela signifie que la legislation actuelle n'est pas adapté à la réalité. Mauvaise legislation, changer legislation. Comment ? ça c'est une autre histoire. Mais il est évident qu'il faut la faire évoluer. C'est ce que dit IBM.
Une solution serait donc de restreindre le type de brevet que l'on peut déposer.
Interdire par exemple les brevets logiciels non liés à un phenomène physique, ce serait déjà un grand pas.
Il y aurait déjà beaucoup moins de vérifications à faire dans l'ensemble. La vérification des autres demandes de brevets "legitimes" serait donc plus approfondies, mieux faîte ;-)
[^] # Re: MS, toujours MS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gnome et OpenDocument. Évalué à 3.
non, tu confonds avec RSS, qui est de Netscape, à l'origine. RDF est un format standardisé par le w3c, et n'a rien à voir avec RSS, si ce n'est que la version 1.0 de RSS utilise RDF pour structurer ses données (alors que les autres versions de RSS, 0.9x et 2.0 utilise le format... rss).
[^] # Re: Versions
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Wiki de code source ?. Évalué à 4.
Maintenant, pour taper du code source, c'est *vachement* plus agréable d'avoir la coloration syntaxique, la completion de code auto etc... Tout ce que tu ne peux pas faire dans une interface web.
# Et silicon, c'est français ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ne m'appelez plus jamais Wi-Fi. Évalué à 5.
Ah lala, ces pseudos journalistes qui veulent se la peter toujours un peu plus... C'est si facile de taper sur quelqu'un ou sur quelque chose. Ça critique, ça critique, mais il propose quoi lui en remplacement ?
[^] # Re: Et ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox supportant le SVG (sous windows) ?. Évalué à 3.
Et xulrunner avec SVG activé : http://xulfr.org/download/XulRunner/(...)
(xulrunner -> http://xulfr.org/wiki/XulRunner)(...)
[^] # Re: Et ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox supportant le SVG (sous windows) ?. Évalué à 2.
Ce qu'il y a de nouveau donc, c'est que
- c'est compilé par défaut (il faut juste l'activer dans les preferences du navigateur)
- et puis surtout, y a de moins en moins de bug dans l'implementation, et s'améliore de semaines en semaines. D'ailleurs, il y a quelques mois, il fallait avoir beaucoup de chance pour que *tout* les exemples SVG de croczilla (http://www.croczilla.com/svg/)(...) tournent correctement. Maintenant il n'y a plus vraiment de problèmes.
[^] # Re: Pas encore ca avec Konqueror
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à -1.
Et pour ton information, les patchs, tu les trouveras sur le premier lien de la news.
Si il fourni des patchs, c'est qu'ils sont un minimum utilisable je pense. Rien n'empeche aux devs de khtml de jeter un coup d'oeil dans les patchs pour avoir une idée de comment david hyatt à résolu les problèmes.
Peut etre même bien que certains patchs concernent des fichiers qui n'ont pas été modifiés dans tous les sens par rapport au tronc de khtml.
Mais ça surement que les dev de khtml, de par leur mécontentement, ne vont même pas chercher à savoir si ils peuvent les appliquer ou pas. je me demande bien si ils ont vraiment jeté un oeil sur ces patchs, et si ils sont pas de mauvaise fois.
[^] # Re: Alors...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 4.
Mozilla = un nom inventé par les fondateurs de Netscape, et signifie Mosaic Killer (killer = gozilla), Mosaic étant l'un des touts premiers (le premier meme il me semble) navigateur web graphique. (souvenir souvenir...)
Le moteur de IE, quant à lui, est dérivé de celui de Mosaic (voir les infos de copyright dans la boite "à propos" de IE).
[^] # Re: De la validité du test
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 4.
Arrrggggg !
Vite, une cure de desintox !
[^] # Re: De la validité du test
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 6.
La norme CSS dit explicitement que toute instruction ou selecteur non conforme à la norme doit être ignorée par les navigateurs.
Cela va donc dire, si il y a une erreur dans le fichier CSS : l'ignorer. Ce que teste Acid2...
Il est même dit dans la norme CSS, que tout navigateur peut supporter *en plus* des styles qui ne sont pas dans la norme. Mais pour cela, il faut prefixer leur nom par "-foo-" où foo désigne le navigateur. Ex dans Mozilla : -moz-border-radius.
[^] # Re: De la validité du test
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 10.
Ceci pour tester que le navigateur n'interprete pas des choses qui ne devrait pas l'être.
Exemple, pour la première erreur, qui est située sur cette ligne
[class=second two] { background: red; } /* this should be ignored (invalid selector -- grammar says it only accepts IDENTs or STRINGs) */
Ces erreurs sont aussi signalées dans le descriptif du test : http://webstandards.org/act/acid2/guide.html(...)
[^] # Re: La moindre des choses
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IE7 supporterait correctement les PNG et les CSS. Évalué à 2.
[^] # Re: La moindre des choses
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IE7 supporterait correctement les PNG et les CSS. Évalué à 4.
Donc une première utilisation basique de XUL serait : je continue de réaliser mes applis web comme d'habitude, je remplace juste HTML par XUL. (ton histoire d'utilisation d'HTTP, ou plutôt de xmlHTTPRequest tu voulais dire je pense, parce que bon, HTTP, tu peux pas t'en passer :-p, enfin bon, ton histoire de xmlHTTPRequest n'a pas lieu d'être dans ce cas )
Une utilisation plus intelligente, c'est je remplace HTML par XUL, mais j'utilise aussi des services web (via xmlHttpRequest). Ça permet plein de choses
- pas de rechargement de l'interface -> economie bande passante, et charge moins importante du serveur (il n'a pas à tout regenerer l'interface, donc éventuellement à faire des dizaines de requetes pour cela)
- séparation en couche : d'un coté l'UI, et de l'autre des services webs. Lesdit services pouvant non seulement être appelés par l'UI, mais également par toutes autres applications (web, desktop..) bref, -> capitalisation des développements.
- ps de rechargement -> interface plus reactive, plus dynamique, tout ce qui est lié à l'interface est fait coté client -> ergonomie améliorée
En tout cas, je ne vois pas en quoi cette tendance à utiliser xmlHTTPRequest a de mauvais. Elle permet de faire des choses vraiment plus simple et plus efficace dans les applications web (pour les *sites* web, c'est autre chose), autant pour le développeur que pour l'utilisateur.
[^] # Re: attention
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche La réaction de Richard Stallman aux récents évènements autour de BitKeeper. Évalué à -1.
# attention
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche La réaction de Richard Stallman aux récents évènements autour de BitKeeper. Évalué à 3.
"Et si vous continuez à les utiliser, vous et votre famille surporteront la colère du guru RMS sur 5 générations, vous serez gangréné par le cancer incurable GPL, vous irez tous en enfer au milieu de pinguoins mangeur d'homme dréssés par Linus, par -50 °C (oui l'enfer ça peut être trés froid il parait), et un déluge d'instructions assembleurs s'abattra sur vous pendant 10 ans si dans 1 mois vous n'avez pas voté OUI aux logiciels libres."
->[] (faut vite que j'aille effacer cette partition windows qui ne me sert plus à grand chose...)
[^] # Re: Je suis pas sur de comprendre ton problème
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal libetc: faire le ménage dans son $HOME, la fin des fichiers de configuration cachés (dotfiles). Évalué à 2.
car il y a des repertoires où tu ne veux pas voir tout les fichiers cachés, et d'autres si (par exemple toujours voir le .htaccess des sites web que l'on developpe)
Et puis moi, j'aime bien voir ce qu'il y a réèllement dans mes répertoires. Sauf mon home car c'est vrai, plus çca va, plus ça devient vraiment le bordel.
Vive le $XDG_CONFIG_HOME .
[^] # Re: XulRunner
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sorties et nouvelles autour de Mozilla. Évalué à 2.
C'est pas le XUL qui permet de faire ça (XUL, c'est le langage d'interface graphique). Mais par contre tu as une API disponible pour tout ce qui est web service (SOAP, XML-RPC, ou encore le fameux xmlhttprequest):
http://xulfr.org/wiki/WebServices(...)
ou plus généralement, faire des ApplisWeb avec les technos de Mozilla :
http://xulfr.org/wiki/ApplisWeb(...)
# Et encore...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'intérêt d'un portail dédié aux développements pour GNU/Linux. Évalué à 4.
Et encore, tu n'as pas regardé du coté de Gecko. Pour développer une appli Mozilla, il faut connaitre : XML en général, XUL, XBL, CSS, XPCOM, Ecmascript, DOM, RDF, le format de package XPI... Et d'autres si on veut aller plus loin (C++, SVG, XSL, SOAP, XML-RPC, XForms, MathML etc..)
Heureusement, y a déjà un site pour ne pas s'y perdre dans tout ça ;-)
[^] # Re: Pitoyable...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le logo debian dans WoW !. Évalué à 3.
:-/
[^] # Re: XUL : Question Rapidité
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sorties et nouvelles autour de Mozilla. Évalué à 2.
Non, ça c'est du XBL :-p (il y a 1 seule balise xul là-dedans)
Mais effectivement, j'ai pas pensé à regarder dans la feuille de style si il y avait des bindings
[^] # Re: XUL : Question Rapidité
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sorties et nouvelles autour de Mozilla. Évalué à 2.
Prometteur ? tu es sur ? pour moi, prometteur, cela veut dire que la techno n'est pas encore disponible. Or ça fait déjà quelques années qu'on peut faire du XUL...
Oui bien sûr. Mais ce n'est pas XUL qui est en cause. C'est gecko, le moteur d'affichage de Mozilla/Firefox/Xulrunner, qui sait afficher tout type de fichier XML (XUL, xml qcq, XHTML, MathML, SVG ...) avec des CSS.
Et dans sa version 1.8, qui devait être utilisé par Mozilla 1.8, gecko est encore plus performant. Il faudra attendre Firefox 1.1 pour s'en rendre compte.
XulRunner ne permet pas d'aller plus vite que Firefox : ils utilisent le même moteur Gecko. Par contre, si plusieurs applis utilisent XulRunner en même temps, on va avoir des améliorations interressantes coté consommation mémoire puisque les libs de Gecko ne seront instanciée qu'une seule fois en mémoire.
Quand je regarde les sources de ce truc, je ne vois le bout d'une balise xul nulle part...
pour ton histoire de lenteur toute fois, je pense que ton pc est un peu vieux car l'exemple que tu donne est parfaitement fluide chez moi (1.8ghz)
# iaorana
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche TAHITI : Last thursday Édition 2.0. Évalué à 2.
Vive les logiciels libres à Tahiti !
# XulRunner
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sorties et nouvelles autour de Mozilla. Évalué à 4.
En fait, XulRunner contient tout ce que contient Firefox et Thunderbird (tout les composants XPCOM et Gecko), sans l'interface de ces produits ;-)
Pour un aperçu de myBrowser : http://ljouanneau.com/blog/2005/04/19/419-xulrunner-en-action(...)
Pour d'autres news sur le sujet : http://xulfr.org/news/(...) et http://xulfr.org/wiki/XulRunner(...)
[^] # Re: Et Seamonkey, ex-Mozilla suite ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sorties et nouvelles autour de Mozilla. Évalué à 1.
Qu'en sait -tu ? tu as une boule de crystal ? C'est pas un troll que tu as lancé, ce sont des suppositions non vérifiées.
Si les dev de Gecko ont choisi d'utiliser Cairo pour tout le reste de l'affichage, c'est certainement qu'ils ont étudié un minimum la lib et qu'ils savent donc qu'il y a moyen d'optimiser, que le cas de Cairo est loin d'être catastrophique.
Maintenant, si tu connais une alternative au moins aussi puissante, plus rapide et sous licence MPL/LGPL, contacte les. (mais te fatigue pas, ils ont surement déjà chercher longtemps)
Bref, ça sert à rien de tenter de troller là où il n'y a pas de troll.
[^] # Re: qu'est-ce qu'on s'marre
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche IBM pour une réforme de la brevetabilité. Évalué à 4.
Dans la mesure où un système n'est pas capable d'absorber ses flux en entrée, il faut changer le système, le modifier.
Le seul moyen actuel pour les organismes de brevet d'absorber le flux, c'est de diminuer les verifications. Ce n'est pas la bonne solution. Si maintenant la legislation dit, ne pas s'occuper de tel ou tel type de demande de brevet, ils ne seront donc pas obliger de traiter ces types de demandes, et pourront faire les verifications qui s'imposent sur les autres.
Si elles acceptent toutefois de traiter les types de brevets non permis, c'est aussi un problème car finalement actuellement rien ne les empeche (et traitent donc mal les bonnes demandes de brevets). Là encore, si une legislation les mettaient à l'amende à chaque dérive, tout se passerait certainement mieux.
Mais cela necessite là encore de changer la legislation. C'est donc bien la législation qu'il faut changer. pas changer les organismes de brevets (les nouveaux feraient exactement les mêmes betises si la legislation leur permet).
[^] # Re: qu'est-ce qu'on s'marre
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche IBM pour une réforme de la brevetabilité. Évalué à 6.
Oui mais ça, c'est la théorie. En pratique, c'est impossible à faire car Il y a trop de vérifications à faire, trop de demande de brevets, trop de brevets déposés.
Comme c'est impossible, cela signifie que la legislation actuelle n'est pas adapté à la réalité. Mauvaise legislation, changer legislation. Comment ? ça c'est une autre histoire. Mais il est évident qu'il faut la faire évoluer. C'est ce que dit IBM.
Une solution serait donc de restreindre le type de brevet que l'on peut déposer.
Interdire par exemple les brevets logiciels non liés à un phenomène physique, ce serait déjà un grand pas.
Il y aurait déjà beaucoup moins de vérifications à faire dans l'ensemble. La vérification des autres demandes de brevets "legitimes" serait donc plus approfondies, mieux faîte ;-)