(Je tiens à faire remarquer que je me place ici dans le cas théorique d'une élection pour laquelle aucun choix ne semble pertinent. Je me garderais bien de proposer ici une « directive de vote » quant au référendum.)
Bon, ceci dit, le problème est que le vote blanc est méchament gommé des statistiques. Luttons pour la prise en compte du vote blanc !
C'est exactement ce que j'ai dit : .Net permet à msh ce genre de manip. et .Net donne une interface objet au SE. Maintenant, que le SE soit codé en .Net ou qu'une api .Net donne cette interface, ça ne change rien, ni à ce que j'ai dit, ni au fonctionnement de msh.
T'es libre[...]intelligent.
Et bien, comme l'a souligné Mc Jo, il s'agit d'un témoignage sous serment qui nous explique le GL tel qu'appliqué dans Windows.
Je n'ai fait que citer une partie de ce témoignage (en donnant le lien pour le témoignage complet pour éviter les remarques du type « The devil can cite Scripture for his purpose » [The Merchant of Venice, I-3, W. Shakespeare]), en en donnant un résumé en français.
Cette citation me permet donc d'expliciter mes sentiments (effectivement, je n'ai ni le code, ni la documentation qui devrait l'accompagner, pour aller jusqu'à juger) sur les liens entre Windows et le GL. Sentiments qui sont confortés par les annonces des fonctionnalités prévues par les futures produits attachés.
[parodie]
Moi y en a espérer que moi y en avoir été assez clair pour que toi pouvoir comprendre quoi moi y en avoir dit.
[/ hommage à Goscinny]
En fait, elle utilise déjà d'autres signaux pour ça. Le problème, c'est qu'ils sont (trop) subtiles ;o)
(sans compter que toutes les copines n'utilisent pas les mêmes, ce serait trop simple ;o)
Je ne reprochais rien à ton message, juste qu'il manquait la considération que j'ai faite, c.-à-d. que debian est/veut_être utilisable de la même façon sur beaucoup d'architectures, ce qui fait que, en partant d'une debian et en limitant les architectures supportées, on arrive à gagner du temps pour peaufiner la reconnaissance automatique de matériel (et ce qui fait aussi que les rilizes debian soient si espacées ;op).
Il ne faut pas oublier que l'installateur debian doit fonctionner sur toutes les architectures supportées (plus de 11 pour sarge ?), alors que, p. ex.:
- knoppix ne propose que i386 ;
- ubuntu propose i386, ppc et amd64 en install et seulement i386 en CD vivant.
(i386 et amd64 partageant quand même plus que fortement ;o) leurs périphériques.)
--
Le choix, c'est la liberté et la liberté, ça fait parfois peur.
Donc ce n'est pas msh qui fait mais ce qu'il y a au dessous de msh (le SE, quoi). Alors ne comparons pas msh et les shells standard. Disons plutôt que msh utilise .Net et que .Net donne une interface objet au SE.
Comme je l'ai dit plus haut, j'oublie toujours que Windows est à la fois un noyau, un SE, un gestionnaire de fenêtres, un bureau...
« For example, the component needed just to run a particular sound card depends upon a great many other components of Windows, in some cases including all of the components involved in providing Web browsing functionality. Certain of these interdependencies may seem counterintuitive, but they reflect basic engineering efficiencies, and they make it extremely difficult to create a version of Windows from which various components could be removed without degrading the rest of the operating system. »
En clair : sous Windows, c'est IE qui gère les cartes sons et c'est normal parce que c'est un principe basique d'efficacité du génie logiciel.
Quand je dis integration avec l'OS, je parles pas du noyau de l'OS
Argh. C'est vrai qu'avec Microsoft, même notepad fait partie de l'OS. :oP
Maintenant, en ce qui concerne le reste du message, les infos existent et sont accessibles : on peut faire une fonction python (ou autre) qui construise un tel objet.
Donc, en ce qui concerne la possibilité, elle est là.
En ce qui concerne l'existence, et bien, encore une fois c'est une question de gain/coût. Effectivement, si toutes les fonctions systèmes étaient en orienté objet, cela serait moins coûteux (à ce sujet, voir les discussions sur « pourquoi pas linux en C++ »). Pour l'intérêt (le gain), s'il s'avère qu'une API objet pour les fonctions système est désirable et désirée, alors la force du LL fait qu'elle verra le jour.
Non, car, comme je le disais, le choix entre faire ou ne pas faire le référendum est en partie fonction des résultats escomptés. Si les estimations se révèlent totalement foireuses, les politiques auront tendances à avoir bien plus peur d'en faire de nouveau la mauvaise expérience (un « non », ça fait tâche sur un cv).
Mais là, nous sommes très cyniques. Si ça se trouve, les politiques sont moins calculateurs que ça...
Bon, ok, c'est peut-être trop gros ça :o)
Mais remarquez que, parfois on leur prête des calculs machiavéliques compliqués et, d'autres fois, on se moque de leurs erreurs grossières (les mêmes, s'entend).
quelle diference alors entre un qui consulte et un qui ne consulte pas si tout le monde doit répondre la "bonne réponse" ?
Un référendum, ça permet au politique (Président, maire, etc.) de se protéger au cas où la décision prise se révèle mauvaise « c'est vous qui avez dit oui/non, c'est pas moi ».
Et puis, ça donne l'impression aux votants qu'ils participent.
À part ça, oui, évidemment, le référendum est posé pour que l'on réponde « oui ».
À noter que c'est toujours « oui », parce que c'est aussi un « oui » à ceux qui la pose et que « non », c'est... négatif (« les Français sont des veaux », on a toujours tendance à suivre).
C'est donc aussi une arme à double tranchant que l'on n'utilise que lorsque l'on pense ne pas se faire mal (ou que les bénéfices sus-cités valent le risque).
Le but du brevet c'est justement faire en sorte que les procédés soient publics et non gardés secrets, afin qu'à terme ils profitent à tous et ne soient pas perdus.
Oui, là, on est d'accord. Mais je réagissais parce que tu parlais des recettes-composants, pas des recettes-procédés.
il manque l'integration au systeme, ce qui est assez vital pour un shell
Ah ? c'est nouveau ?
Un shell sert à lancer des programmes et fournit quelques commandes de base pour les composer ou manipuler les jobs. Ce sont là quelques fonctions système. Pas besoin de pouvoir tripoter toutes les données du noyau.
Oui, et quid des 26500 autres exemples que je pourrais te sortir ?
Je répondais juste pour cet exemple. Si tu m'en sors 26500 autres (et si j'en avais le temps, mais, au lieu de ça, je moule sur linuxfr...), je pense qu'on pourrait trouver une solution pour chacun.
Mais justement, ces commandes shell sont petites, ce sont des commandes generiques.
Je ne sais pas, je n'ai pas vu le code, mais cela dépasse un peu ce qu'un shell est censé faire (p.ex. cp et mv sont des programmes, pas des commandes).
Justement non, c'est le truc.
Le commande sort, elle n'a aucune idee a l'avance que l'objet qu'elle va recevoir a une propriete nommee "date" ou "version", sort est un outil generique et quand tu lui passe l'argument "date", alors il va aller le chercher sur l'objet et faire le tri avec ca.
Je n'ai jamais dit que sort doit savoir à l'avance la liste des attributs disponibles. Imagine que le ls modifié envoie la ligne "taille version nom droits ..." suivi de lignes contenant chacune la valeur de ces attributs pour les fichiers cibles (en clair, il indique le format des données juste avant les données).
Le programme sort commence donc par voir arriver "taille version nom droits ..." et comprends que les attributs seront "taille", "version", "nom", etc., et pourra lire les données qui suivent.
« Small is beautiful » est le leitmotiv des outils unix : pas la peine de compliquer, chacun sa spécialité. Si je fais un ls modifié, un sort modifié, etc., je complique ces programmes. Alors que si je fais juste quelques filtres entre eux, je n'ai besoin que de programmes simples. Ok, ma ligne de commande est plus longue, mais si je m'en sers souvent, je fais des scripts, des fonctions.
De plus, si je tiens à faire ces programmes modifiés, je peux les faire simplement sans pour cela modifier le shell ou, pire, le noyau.
J'y répondrai quand même (j'suis maso, moi, des fois).
Paie-moi !
Personnellement, je n'en ai pas le besoin. Quand bien même je l'aurais, je ferais comme certains (beaucoup ?) ont déjà dû le faire : quelques fonctions shell (avec l'aide de awk ou autre) pour les scripts pour lesquels j'en aurais besoin. Rien de très distribuable, donc (rapport gain/coût* pas intéressant pour moi).
* : je ne parle pas (seulement) de gain/coût financier, il faut certes que je mange et que le temps passé ne m'en empêche pas, je parle aussi du travail nécessaire (pour avoir un bon format) et de l'intérêt qu'une telle bibliothèque puisse vraiment avoir (pour les utilisations triviales, awk suffit, même si c'est « mois élégant »).
Sauf que quand tu dis qu'un alliage est un procédé technique de fabrication, tu peux aussi dire que le format mpeg est un procédé technique de restitution de la vidéo.
Stop ! Je n'ai pas dit que l'alliage était un procédé ! J'ai dit que le brevet porte sur le procédé, pas sur la composition de l'alliage.
De même pour le format, comme je le disais plus loin, un format n'est pas un procédé.
Quand tu dis que les formules chimiques ne sont pas brevetables mais qu'un procédé pour construire un arrangement précis de mollécules l'est .. quelle limite met tu entre la réaction chimique et l'effet obtenu par la réaction chimique ?
Mauvaise interprétation encore : le procédé permettant d'obtenir un composé chimique n'est pas la formule chimique, c'est la mise en ½uvre de celle-ci. P. ex, tu as peut-être fait du nylon au lycée (moi, oui ; en tout cas, c'est pour l'ex.). Le nylon a une formule chimique (zut, j'ai tout oublié ;o). Pour obtenir du nylon, il faut mélanger les bons produits, _de_la_bonne_façon_, et, il y a un _procédé_ pour en tirer un fil. Ce sont la façon et le procédé qui sont brevetables.
Par parrallèle pourquoi ne dis t'on pas que les algo mathématiques ne sont pas brevetables mais que les procédés pour construire un effet logiciel le sont ?
Parce qu'un « effet logiciel », ça ne veut rien dire (en tout cas pour moi, mais « trust me, I'm a doctor »). Et si tant est que cela puisse dire quelque chose, ce qui est logiciel est produit par des logiciels (si, si), donc ces procédés qui construiraient un effet logiciel seraient eux-mêmes des logiciels (tu peux remplacer logiciel par algorithme dans cette phrase, ou dans toute autre d'ailleurs).
Tu dis que le logiciel est un ensemble d'algorithmes mathématiques. Pourquoi ne dis tu pas que le procédé pour l'alliage est un ensemble de réactions chimiques et que les réactions chimiques ne sont pas brevetables ?
Les formules chimiques ne sont pas brevetables. Je le dis.
Tu pourras toujours réduire un procédé à un ensemble d'actions élémentaires et dire que ces actions élémentaires ne sont pas brevetables.
Non. Ce n'est pas une question d'élémentarité des actions. D'ailleurs, au passage, lorsque je dis qu'un logiciel est composé d'algorithmes, cela signifie simplement que l'algorithme principal qu'est le logiciel peut-être décomposé en sous-algorithmes (réutilisation d'algo connus, étudiés, etc.).
Le fait est qu'un logiciel de restitution vidéo (ce n'est qu'un exemple) n'a rien d'une application bête et méchante d'une formule mathématique connue.[...]
La non-brevetabilité des formules mathématiques n'a rien à voir avec le fait qu'elles sont connues, simples ou évidentes, mais parce qu'elles sont de « pures ½uvres de l'esprit » (termes juridiques), c'est-à-dire des idées. On ne brevette pas des idées (car on ne peut prouver que B n'a pas eu la même idée que A sans aucune influence de A), on brevette des _mises_en_½uvre_.
Pour la suite de l'argumentation de ton paragraphe, voir plus haut sur l'élémentarité.
Dans ton dernier paragraphe tu sembles dire que tout ce qui est logiciel tombe sous le sens, je ne suis pas d'accord.[...]
Je n'ai pas dit ça. Dans ce paragraphe, je dis que les propos de l'informatique sont les logiciels, qui sont de « pures ½uvres de l'esprit ». Encore une fois, la différence ne se situe pas au niveau de l'élémentarité ou de la simplicité mais de la _nature_ de ce qui est manipulé et de ce qui manipule.
Mouais, enfin le brevet c'est toujours sur un procédé, le procédé c'est toujours une oeuvre de l'esprit.
Pas sa mise en ½uvre. Elle fait participer de la matière. Les logiciels ne font participer que des symboles.
Note : c'est justement pour éviter ça qu'ont été créé les brevets.
Faux. Les brevets ont été créés pour protéger des savoir-faire (procédé), des « recettes » secrètes (en prenant « recette » dans le sens de procédé, pas de composition).
En disant ça tu donnes plutot un bon argument "pour" la brevetabilité des formats quand ils représentent une innovation techniques.
Non. Un format est une recette au sens de composition. Pour prendre un exemple externe, prenons le Coca Cola. La composition et la recette en sont secrètes, mais seule la recette est brevetable. La composition est gardée secrète car la recette serait facile à découvrir si on en avait les composants.
Maintenant, le problème du coca, c'est que la recette n'est pas bien compliquée (je suppose) : il doit suffire de mélanger les composants (à la rigueur un certain ordre peut être préféré, mais bon, il n'y a pas d'½ufs à battre de telle ou telle manière, à incorporer à telle ou telle température, etc.). Donc, breveter la recette mais distribuer la composition est un danger pour le monopole de la compagnie : on doit pouvoir trouver une recette différente qui donne le même résultat (recette qui serait d'ailleurs elle-même brevetable).
Dans tout ça je ne vois nul part un argument convaincant pour différencier le logiciel du reste. Le "c'est un logiciel" ou "c'est composé d'algo" n'en sont pas vraiment.
Un bon article paru sur un Linux Magazine à ce sujet c'est http://jjdj.free.fr/article/index.html(...)(...) . Il explique bien pourquoi l'exclusion actuelle est juste là pour éviter qu'on ne considère un logiciel comme technique "parce que c'est un logiciel", mais n'interdit pas du tout la brevetabilité du logiciel ou de quelque chose qui contient du logiciel si le brevet couvre l'effet obtenu par un procédé technique innovant (le procédé pouvant être logiciel ou pas, peu importe).
Ce que je trouve effectivement stupide mais c'est un compromis (« un compromis, c'est quand tout le monde perd »), ce qui rend le texte bancale à mon goût.
Puisqu'on en est à la correction de l'adage, celui-ci est un vers de La Fontaine (je ne sais plus quelle fable, mais ça doit se trouver... merci google : L'Ours et les deux Compagnons), et je profite de cette tribune pour rectifier, la morale en est :
« il ne faut jamais vendre la peau de l'Ours qu'on ne l'ait mis par terre. »
Je pense que tu cites mal à propos : en parlant de Turing, je voulais dire qu'au niveau calculabilité (donc fonctionnalités), on ne peut pas faire plus (mais on peut effectivement faire plus facile ou plus élégant).
Sinon, l'exemple que tu donnes est traitable facilement avec find (sauf le n° de version, mais c'est parce que le n° de version ne se trouve pas être un attribut du fichier dans le système de fichiers).
De la même façon, « small is beautiful » et je pense que ces fonctions appartiennent à des programmes, pas à des commandes shell (nuance importante dans la discussion qui nous occupe).
Le principe est que se sont des octets qui passent par les tubes (pipes). Les « shells standard » conservent ce principe. Quelques commandes et programmes simplifient un peu et ne traitent que des caractères.
Mais rien n'empêche de créer un format d'échange de données « objet » (ce ne sont pas vraiment des objets mais plutôt des structures, mais bon, on va dire « objet » pour simplifier, je vais pas expliquer CORBA ici). Si tu as deux commandes qui connaissent ce format et que tu associes par un tube, p.ex. un ls qui donne les infos sur les fichiers sous forme d'objets, et un sort qui sait les lire et dont la syntaxe des arguments te permet de les manipuler, tu as l'équivalent (j'oserais dire « la même chose ») que ce que propose msh.
Et, pour cela, pas besoin de rajouter des fonctionnalités au shell ou au noyau. Une simple bibliothèque pour gérer ce format suffit (histoire de standardiser ledit format).
la maniere dont il fait cela est assez hors du commun et plutot baleze.
Euh, la manière, c'est « Pourquoi faire simple quand on peut faire compliqué ? » ?
hop, hop, trop facile -->[]
Plus sérieusement, ne peut-on pas simuler un machine de Turing avec un « shell standard » ? Je pense que si...
Ah, pardon, tu parlais peut-être de la possibilité de tripoter la mémoire des autres processus, surtout la mémoire du noyau. Là, effectivement, les « shells standard » ne savent/peuvent pas faire.
La méthode de production de l'alliage est un procédé technique de fabrication. C'est purement ce pour quoi les brevets ont été créés : protéger des secrets de fabrication pour permettre leur diffusion sans qu'il n'y ait risque de perte de cette connaissance à la disparition de ses détenteurs, pas leur résultat (ce n'est pas l'alliage qui est breveté).
Effectivement, je trouve personnellement le brevetage d'un gène « en tant que tel » complètement stupide. D'après ce que je sais, il serait question du brevetage des méthodes de séquençage (mais je n'ai jamais creusé la question des brevets « sur » les gènes).
Un format de données, c'est un arrangement particulier de ces données. Je ne crois pas que les formules chimiques soient brevetables, seulement les procédés pour produire les molécules/arrangements correspondants. Par similitude, ce serait donc les logiciels de codage/décodage (transformation depuis/vers un autre format) qui pourraient donner occasion à brevet. Or, un logiciel, c'est un ensemble d'algorithmes. Un algorithme, c'est une formule mathématique. Breveter une formule mathématique est une stupidité.
Donc, breveter un format ne veut pas dire grand'chose. Par contre, l'on peut vouloir conserver son format secret, ne le diffuser que sous licence.
Quant à « L'informatique n'a rien de moins "appliqué" que le reste. », je dirais simplement que l'informatique, c'est la production et l'étude de logiciels (tout ou partie) (qui sont de pures ½uvres de l'esprit). Au contraire, la chimie, p.ex., est l'étude de la matière et de ses réactions, pour cela, des procédés de manipulation sont inventés (= découverts). Donc, le chercheur en chimie, physique, etc., poura avoir besoin de procédés, qu'il pourra breveter. L'informaticien utilise et produit des logiciels, pour lesquels il n'a besoin d'aucun procédé autre que des procédés de manipulation de données : des logiciels.
Un ami suisse (qui a émigré depuis), quand on lui disait « C'est beau la Suisse. », répondait « Oui, les musées aussi. Vous aimeriez vivre dans un musée ? ».
Enfin, je dis ça, c'est juste pour dire... parce que, sinon, la Suisse, c'est joli. :oP
[^] # Re: Vive la Suisse
Posté par Sylvain Sauvage . En réponse à la dépêche La brevetabilité des inventions mises en oeuvre par ordinateur adoptée par le Conseil. Évalué à 2.
[^] # Re: CONSTITUTION EUROPEENNE.
Posté par Sylvain Sauvage . En réponse à la dépêche Le Danemark s'opposera au passage en point A. Évalué à 2.
[^] # Re: Constitution européenne
Posté par Sylvain Sauvage . En réponse à la dépêche Le Danemark s'opposera au passage en point A. Évalué à 2.
(Je tiens à faire remarquer que je me place ici dans le cas théorique d'une élection pour laquelle aucun choix ne semble pertinent. Je me garderais bien de proposer ici une « directive de vote » quant au référendum.)
Bon, ceci dit, le problème est que le vote blanc est méchament gommé des statistiques. Luttons pour la prise en compte du vote blanc !
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 2.
T'es gentil, tu restes poli.
C'est exactement ce que j'ai dit : .Net permet à msh ce genre de manip. et .Net donne une interface objet au SE. Maintenant, que le SE soit codé en .Net ou qu'une api .Net donne cette interface, ça ne change rien, ni à ce que j'ai dit, ni au fonctionnement de msh.
[^] # Re: Un autre gadget....
Posté par Sylvain Sauvage . En réponse au sondage Le gadget geek ultime. Évalué à 2.
Même s'il a des amis, ceux-ci sont des geeks et la communication se fait sur IP.
[^] # Re: Gadgets à inventer
Posté par Sylvain Sauvage . En réponse au sondage Le gadget geek ultime. Évalué à 4.
(sans compter que toutes les copines n'utilisent pas les mêmes, ce serait trop simple ;o)
[^] # Re: [X] La table basse de salon connectée en ethernet
Posté par Sylvain Sauvage . En réponse au sondage Le gadget geek ultime. Évalué à 8.
Et le féminin est indéterminable... ;o)
[^] # Re: Et si tu utilisais des distribs vraiment stable ?
Posté par Sylvain Sauvage . En réponse au journal #kubuntu ou le coté le plus hideux de linux. Évalué à 2.
[^] # Re: Et si tu utilisais des distribs vraiment stable ?
Posté par Sylvain Sauvage . En réponse au journal #kubuntu ou le coté le plus hideux de linux. Évalué à 2.
- knoppix ne propose que i386 ;
- ubuntu propose i386, ppc et amd64 en install et seulement i386 en CD vivant.
(i386 et amd64 partageant quand même plus que fortement ;o) leurs périphériques.)
--
Le choix, c'est la liberté et la liberté, ça fait parfois peur.
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 1.
Comme je l'ai dit plus haut, j'oublie toujours que Windows est à la fois un noyau, un SE, un gestionnaire de fenêtres, un bureau...
Ça me fait penser à ça :
[ Paragraphe 222 du témoignage de Bill Gates lors du procès contre l'État de New York, « enlever Internet Explorer de Windows ».
http://www.microsoft.com/presspass/legal/billgates/billgates.asp(...) ]
« For example, the component needed just to run a particular sound card depends upon a great many other components of Windows, in some cases including all of the components involved in providing Web browsing functionality. Certain of these interdependencies may seem counterintuitive, but they reflect basic engineering efficiencies, and they make it extremely difficult to create a version of Windows from which various components could be removed without degrading the rest of the operating system. »
En clair : sous Windows, c'est IE qui gère les cartes sons et c'est normal parce que c'est un principe basique d'efficacité du génie logiciel.
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 1.
Argh. C'est vrai qu'avec Microsoft, même notepad fait partie de l'OS. :oP
Maintenant, en ce qui concerne le reste du message, les infos existent et sont accessibles : on peut faire une fonction python (ou autre) qui construise un tel objet.
Donc, en ce qui concerne la possibilité, elle est là.
En ce qui concerne l'existence, et bien, encore une fois c'est une question de gain/coût. Effectivement, si toutes les fonctions systèmes étaient en orienté objet, cela serait moins coûteux (à ce sujet, voir les discussions sur « pourquoi pas linux en C++ »). Pour l'intérêt (le gain), s'il s'avère qu'une API objet pour les fonctions système est désirable et désirée, alors la force du LL fait qu'elle verra le jour.
[^] # Re: Constitution européenne
Posté par Sylvain Sauvage . En réponse à la dépêche Le Danemark s'opposera au passage en point A. Évalué à 2.
Mais là, nous sommes très cyniques. Si ça se trouve, les politiques sont moins calculateurs que ça...
Bon, ok, c'est peut-être trop gros ça :o)
Mais remarquez que, parfois on leur prête des calculs machiavéliques compliqués et, d'autres fois, on se moque de leurs erreurs grossières (les mêmes, s'entend).
[^] # Re: Constitution européenne
Posté par Sylvain Sauvage . En réponse à la dépêche Le Danemark s'opposera au passage en point A. Évalué à 2.
Un référendum, ça permet au politique (Président, maire, etc.) de se protéger au cas où la décision prise se révèle mauvaise « c'est vous qui avez dit oui/non, c'est pas moi ».
Et puis, ça donne l'impression aux votants qu'ils participent.
À part ça, oui, évidemment, le référendum est posé pour que l'on réponde « oui ».
À noter que c'est toujours « oui », parce que c'est aussi un « oui » à ceux qui la pose et que « non », c'est... négatif (« les Français sont des veaux », on a toujours tendance à suivre).
C'est donc aussi une arme à double tranchant que l'on n'utilise que lorsque l'on pense ne pas se faire mal (ou que les bénéfices sus-cités valent le risque).
[^] # Re: Grrr
Posté par Sylvain Sauvage . En réponse à la dépêche La Commission refuse une nouvelle première lecture. Évalué à 2.
Oui, là, on est d'accord. Mais je réagissais parce que tu parlais des recettes-composants, pas des recettes-procédés.
Moi pas. ;op
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 3.
Ah ? c'est nouveau ?
Un shell sert à lancer des programmes et fournit quelques commandes de base pour les composer ou manipuler les jobs. Ce sont là quelques fonctions système. Pas besoin de pouvoir tripoter toutes les données du noyau.
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 2.
Je répondais juste pour cet exemple. Si tu m'en sors 26500 autres (et si j'en avais le temps, mais, au lieu de ça, je moule sur linuxfr...), je pense qu'on pourrait trouver une solution pour chacun.
Je ne sais pas, je n'ai pas vu le code, mais cela dépasse un peu ce qu'un shell est censé faire (p.ex. cp et mv sont des programmes, pas des commandes).
Je n'ai jamais dit que sort doit savoir à l'avance la liste des attributs disponibles. Imagine que le ls modifié envoie la ligne "taille version nom droits ..." suivi de lignes contenant chacune la valeur de ces attributs pour les fichiers cibles (en clair, il indique le format des données juste avant les données).
Le programme sort commence donc par voir arriver "taille version nom droits ..." et comprends que les attributs seront "taille", "version", "nom", etc., et pourra lire les données qui suivent.
« Small is beautiful » est le leitmotiv des outils unix : pas la peine de compliquer, chacun sa spécialité. Si je fais un ls modifié, un sort modifié, etc., je complique ces programmes. Alors que si je fais juste quelques filtres entre eux, je n'ai besoin que de programmes simples. Ok, ma ligne de commande est plus longue, mais si je m'en sers souvent, je fais des scripts, des fonctions.
De plus, si je tiens à faire ces programmes modifiés, je peux les faire simplement sans pour cela modifier le shell ou, pire, le noyau.
« Pouf, ah puh magie ! »
[^] # Re: Oui, mais ...
Posté par Sylvain Sauvage . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 2.
(Ça fonctionne aussi très bien avec des noyaux de kernel.org !)
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 2.
J'y répondrai quand même (j'suis maso, moi, des fois).
Paie-moi !
Personnellement, je n'en ai pas le besoin. Quand bien même je l'aurais, je ferais comme certains (beaucoup ?) ont déjà dû le faire : quelques fonctions shell (avec l'aide de awk ou autre) pour les scripts pour lesquels j'en aurais besoin. Rien de très distribuable, donc (rapport gain/coût* pas intéressant pour moi).
* : je ne parle pas (seulement) de gain/coût financier, il faut certes que je mange et que le temps passé ne m'en empêche pas, je parle aussi du travail nécessaire (pour avoir un bon format) et de l'intérêt qu'une telle bibliothèque puisse vraiment avoir (pour les utilisations triviales, awk suffit, même si c'est « mois élégant »).
[^] # Re: Grrr
Posté par Sylvain Sauvage . En réponse à la dépêche La Commission refuse une nouvelle première lecture. Évalué à 2.
Stop ! Je n'ai pas dit que l'alliage était un procédé ! J'ai dit que le brevet porte sur le procédé, pas sur la composition de l'alliage.
De même pour le format, comme je le disais plus loin, un format n'est pas un procédé.
Mauvaise interprétation encore : le procédé permettant d'obtenir un composé chimique n'est pas la formule chimique, c'est la mise en ½uvre de celle-ci. P. ex, tu as peut-être fait du nylon au lycée (moi, oui ; en tout cas, c'est pour l'ex.). Le nylon a une formule chimique (zut, j'ai tout oublié ;o). Pour obtenir du nylon, il faut mélanger les bons produits, _de_la_bonne_façon_, et, il y a un _procédé_ pour en tirer un fil. Ce sont la façon et le procédé qui sont brevetables.
Parce qu'un « effet logiciel », ça ne veut rien dire (en tout cas pour moi, mais « trust me, I'm a doctor »). Et si tant est que cela puisse dire quelque chose, ce qui est logiciel est produit par des logiciels (si, si), donc ces procédés qui construiraient un effet logiciel seraient eux-mêmes des logiciels (tu peux remplacer logiciel par algorithme dans cette phrase, ou dans toute autre d'ailleurs).
Les formules chimiques ne sont pas brevetables. Je le dis.
Non. Ce n'est pas une question d'élémentarité des actions. D'ailleurs, au passage, lorsque je dis qu'un logiciel est composé d'algorithmes, cela signifie simplement que l'algorithme principal qu'est le logiciel peut-être décomposé en sous-algorithmes (réutilisation d'algo connus, étudiés, etc.).
La non-brevetabilité des formules mathématiques n'a rien à voir avec le fait qu'elles sont connues, simples ou évidentes, mais parce qu'elles sont de « pures ½uvres de l'esprit » (termes juridiques), c'est-à-dire des idées. On ne brevette pas des idées (car on ne peut prouver que B n'a pas eu la même idée que A sans aucune influence de A), on brevette des _mises_en_½uvre_.
Pour la suite de l'argumentation de ton paragraphe, voir plus haut sur l'élémentarité.
Je n'ai pas dit ça. Dans ce paragraphe, je dis que les propos de l'informatique sont les logiciels, qui sont de « pures ½uvres de l'esprit ». Encore une fois, la différence ne se situe pas au niveau de l'élémentarité ou de la simplicité mais de la _nature_ de ce qui est manipulé et de ce qui manipule.
Pas sa mise en ½uvre. Elle fait participer de la matière. Les logiciels ne font participer que des symboles.
Faux. Les brevets ont été créés pour protéger des savoir-faire (procédé), des « recettes » secrètes (en prenant « recette » dans le sens de procédé, pas de composition).
Non. Un format est une recette au sens de composition. Pour prendre un exemple externe, prenons le Coca Cola. La composition et la recette en sont secrètes, mais seule la recette est brevetable. La composition est gardée secrète car la recette serait facile à découvrir si on en avait les composants.
Maintenant, le problème du coca, c'est que la recette n'est pas bien compliquée (je suppose) : il doit suffire de mélanger les composants (à la rigueur un certain ordre peut être préféré, mais bon, il n'y a pas d'½ufs à battre de telle ou telle manière, à incorporer à telle ou telle température, etc.). Donc, breveter la recette mais distribuer la composition est un danger pour le monopole de la compagnie : on doit pouvoir trouver une recette différente qui donne le même résultat (recette qui serait d'ailleurs elle-même brevetable).
Je pense que si. J'espère que mes explications sont plus claires maintenant.
Sinon, tu as aussi http://wiki.ffii.org/index.cgi?Epue52filmFr(...) , p. ex.
Ce que je trouve effectivement stupide mais c'est un compromis (« un compromis, c'est quand tout le monde perd »), ce qui rend le texte bancale à mon goût.
[^] # Re: Pas de précipitation, il y a le week end à passer...
Posté par Sylvain Sauvage . En réponse à la dépêche Le Danemark s'opposera au passage en point A. Évalué à 10.
« il ne faut jamais vendre la peau de l'Ours qu'on ne l'ait mis par terre. »
Je sais, tout le monde s'en fout. --> []
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 4.
Sinon, l'exemple que tu donnes est traitable facilement avec find (sauf le n° de version, mais c'est parce que le n° de version ne se trouve pas être un attribut du fichier dans le système de fichiers).
De la même façon, « small is beautiful » et je pense que ces fonctions appartiennent à des programmes, pas à des commandes shell (nuance importante dans la discussion qui nous occupe).
Le principe est que se sont des octets qui passent par les tubes (pipes). Les « shells standard » conservent ce principe. Quelques commandes et programmes simplifient un peu et ne traitent que des caractères.
Mais rien n'empêche de créer un format d'échange de données « objet » (ce ne sont pas vraiment des objets mais plutôt des structures, mais bon, on va dire « objet » pour simplifier, je vais pas expliquer CORBA ici). Si tu as deux commandes qui connaissent ce format et que tu associes par un tube, p.ex. un ls qui donne les infos sur les fichiers sous forme d'objets, et un sort qui sait les lire et dont la syntaxe des arguments te permet de les manipuler, tu as l'équivalent (j'oserais dire « la même chose ») que ce que propose msh.
Et, pour cela, pas besoin de rajouter des fonctionnalités au shell ou au noyau. Une simple bibliothèque pour gérer ce format suffit (histoire de standardiser ledit format).
[^] # Re: Doucement doucement!
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 5.
Parce que MS a déjà fait des versions définitives de ses produits ?
hop, hop -->[]
[^] # Re: petit plus
Posté par Sylvain Sauvage . En réponse au journal Devdays, Le Futur de microsoft, je suis rassuré. Évalué à 0.
Euh, la manière, c'est « Pourquoi faire simple quand on peut faire compliqué ? » ?
hop, hop, trop facile -->[]
Plus sérieusement, ne peut-on pas simuler un machine de Turing avec un « shell standard » ? Je pense que si...
Ah, pardon, tu parlais peut-être de la possibilité de tripoter la mémoire des autres processus, surtout la mémoire du noyau. Là, effectivement, les « shells standard » ne savent/peuvent pas faire.
rehop, rehop, pour de bon -->[]
[^] # Re: Grrr
Posté par Sylvain Sauvage . En réponse à la dépêche La Commission refuse une nouvelle première lecture. Évalué à 3.
Effectivement, je trouve personnellement le brevetage d'un gène « en tant que tel » complètement stupide. D'après ce que je sais, il serait question du brevetage des méthodes de séquençage (mais je n'ai jamais creusé la question des brevets « sur » les gènes).
Un format de données, c'est un arrangement particulier de ces données. Je ne crois pas que les formules chimiques soient brevetables, seulement les procédés pour produire les molécules/arrangements correspondants. Par similitude, ce serait donc les logiciels de codage/décodage (transformation depuis/vers un autre format) qui pourraient donner occasion à brevet. Or, un logiciel, c'est un ensemble d'algorithmes. Un algorithme, c'est une formule mathématique. Breveter une formule mathématique est une stupidité.
Donc, breveter un format ne veut pas dire grand'chose. Par contre, l'on peut vouloir conserver son format secret, ne le diffuser que sous licence.
Quant à « L'informatique n'a rien de moins "appliqué" que le reste. », je dirais simplement que l'informatique, c'est la production et l'étude de logiciels (tout ou partie) (qui sont de pures ½uvres de l'esprit). Au contraire, la chimie, p.ex., est l'étude de la matière et de ses réactions, pour cela, des procédés de manipulation sont inventés (= découverts). Donc, le chercheur en chimie, physique, etc., poura avoir besoin de procédés, qu'il pourra breveter. L'informaticien utilise et produit des logiciels, pour lesquels il n'a besoin d'aucun procédé autre que des procédés de manipulation de données : des logiciels.
QED
[^] # Re: Et pendant ce temps...
Posté par Sylvain Sauvage . En réponse à la dépêche La TNT est arrivée en France depuis le 28 février. Évalué à 3.
Enfin, je dis ça, c'est juste pour dire... parce que, sinon, la Suisse, c'est joli. :oP