En effet. D'ailleurs, la recherche a interet a utiliser un modele chaotique, pour une raison evoquee par Linus. Si on sait ou on veut aller, la planification est le moyen le plus rapide pour y aller. Le probleme, c'est comment savoir ou on veut aller. Et la planification n'est d'aucun secours dans ce das. Mieux vaut partir dans toutes les directions pour garder celle qui s'avere etre la bonne (pour peu qu'il y est une telle bonne direction).
Il se trouve que le developpement de Linux suit un peu le modele de la recherche. Il est parti d'un modele existant, Unix, mais le but est bien de faire mieux, meme si ca implique de se demarquer du modele original.
A propos de cathedrales: ca me fait penser a la cathedrale et au bazard.
L'idee de Linus consistant a "partir dans toutes les directions et garder la meilleure" marche bien pour Linux, parcequ'il n'y a pas de limites sur le nombre de developpeurs et testeurs (enfin presque). Mais Linux est un cas bien a part de projet libre.
Pour le reste du logiciel, a savoir le logiciel proprietaire developpe par une dizaine de programmeurs, il est essentiel de gagner en efficacite. Le design est une tentative dans cette direction, et l'experience tendrait a montrer que c'est une bonne idee. Le gain en efficacite passe en general par la reduction du chaos.
C'est marrant que tu cites l'exemple des cathedrales, parceque je ne suis pas sur qu'elles etaient construites avec des plans detailles a l'appui.
En plus, l'architecte changeait plusieurs fois, et chaque nouvel architecte apportait sa propre touche. En general, on peut meme le remarquer, dans la mesure ou de nombreuses cathedrales melangent les styles. Ca va plus loin que la decoration, il y a meme des fois ou des "extensions" sont rajoutees apres coup (une tour suplementaire, par exemple).
Nombre de cathedrales ont ete partiellement detruites (incendies, guerre) et reconstruites en suivant une nouvelle orientation.
Pour moi, une cathedrale est plutot un exemple de "conception a geometrie variable".
Autre exemple: les caravelles. J'ai appris cet ete qu'elles etaient construites sans plan general, sans calcul. Certes, ca a eu des consequences, dans la mesure ou certaines coulaient peu apres leur mise a flot. Mais globalement, elles ont permis la mise au point des navires actuels. Si les concepteurs de l'epoque s'etaient emmelles les pinceaux dans le processus de realisation d'un plan qu'il ne pouvait maitriser, les navires ne seraient sans doute pas ce qu'ils sont aujourd'hui.
Attention aux citations hors-contexte, ca peut etre dangereux.
Quand tu cites "tous les gros projets reussis ont ete realise sans design", tu fais peut-etre reference a ce passage:
And I will go further and claim that _no_ major software project that has
been successful in a general marketplace (as opposed to niches) has ever
gone through those nice lifecycles they tell you about in CompSci classes
Linus ne dit pas la que le design ne sert a rien, il dit juste qu'il ne faut pas se fixer sur la theorie apprise a l'ecole. De plus, il parle ici uniquement d'une partie du logiciel (celui qui ne se limite pas a une niche).
L'argumentation de Linus, telle que je la comprends est la suivante:
- La planification detaillee n'est pas indispensable. Exemple: l'evolution
- Dans le cas du logiciel, une planification a long terme est nefaste. Exemples: 1. Les logiciels de SUN se cantonnent a une niche (SUN etant le champion de la planification a long terme) et vont bientot disparaitre (c'est sa prevision, pas la mienne, hein!) . 2. Ceux qui disent que Linux est le resultat d'une planification a long terme ont tort. On peut le croire, il doit savoir de quoi il parle.
j'aime bcp l'idee du hall of shame du kernel, et il faudrait l'etendre à l'ensemble des projets, personne a un site comme ca, genre beurkcode.org ?
Et moi je suis contre. La notion de beaute est tres sujective, c'est bien connu. Surtout quand on parle de code. Sortir un morceau de code de son contexte et dire c'est laid, c'est facile.
100% des programmeurs que je connais (y compris moi) pensent qu'ils sont des programmeurs propres. A se demander pourquoi il y a autant de code sale.
Qu'on rale apres ceux qui ne suivent pas les conventions de codage, c'est normal. Mais si tous ceux qui tombent sur un morceau de code "sale" devaient se plaindre, on en finirait plus.
Je viens de reflechir 5 mn aux nombres univers et aux algorithmes pour les generer. A mon avis, il n'existe pas d'algorithme fini permettant de generer de tels nombres.
Pire encore, je pense qu'un algorithme generant un nombre univers ne peut pas etre encodable par quelquechose de "plus petit" qu'un nombre univers.
Ouf, l'innovation est sauve ;)
Un mathematicien est-il present dans la salle pour confirmer/infirmer mes delires ?
On s'en fiche que l'assertion "Le plus grand nombre premier connu a ce jour" soit fausse. La loi n'interdit pas de dire des trucs cons (heureusement, sinon il y aurait beaucoup de gens en prison...).
En continuant avec les nombres, il me semble qu'il existe des nombres "univers" qui codent toute information imaginable (et inimaginable aussi).
Autrement dit, il existe un nombre qui contient la declaration des droits de l'homme, la Bible et le Coran, toutes vos conversations telephoniques, les reponses a toutes les questions et... toutes les innovations technologiques.
Je ne sais pas si on connait un algorithme pour generer un tel nombre, mais si c'est le cas, celui qui le trouve a interet a deposer un brevet dessus. Toute decouverte posterieure n'en sera plus une, et des royalties devront etre versees...
Et si les terroristes n'avaient tout simplement pas crypte leurs mails ? C'est le meilleur moyen de ne pas attirer l'attention. Toute la puissance electronique du monde aura bien du mal a identifier une correspondance suspecte pourtant echangee en clair. On ne crypte que ce qui doit rester longtemps secret. La preuve: les terroristes ont laisse des tas de manuels de vols derriere eux. Ils s'en fichaient pas mal qu'on decouvre apres coup qu'ils avaient prevu leur attaque et pris des lecons de vols.
La verification a pour but de produire des programmes comprenant moins de bugs.
Le schema de developpement d'un logiciel actuel est le suivant:
1. Etude des besoins
2. Conception du logiciel
3. Implementation
4. Tests
5. Suivant les resultats des tests, retour en 2 ou 3.
Avec verification:
1. Etude des besoins
2. Conception informelle
3. Ecriture d'une specification formelle
4. Implementation
5. Verification
6. Retour en 4.
Le point important est l'etape 3. On ecrit dans un langage mathematique ce que le code doit faire. A partir de ca, on peut verifier que l'implementation respecte la specification.
Dans le cas de jeda, ce n'est pas de la verification qui est faite, mais plutot du test. A partir de la specification, on genere les tests pour tester que le programme est correct.
Un petit exemple: Specification: f est un fonction de N dans N tel que: pour tout n>0, f(n) est pair. Implementation:
int f(int n) {
return 2*n;
}
Tester revient a regarder la valeur de f(n) pour 1000 n differents (par exemple).
Une verification analyse le code source, et prouve que toute valeur retournee par f est pair. Ici c'est "evident", vu qu'un entier positif multiplie par 2 est toujours pair (il y a un piege, cependant, la fonction ne manipule qu'un sous-ensemble des entiers)
Traditionnellement (pour la plupart des LL, par exemple), aucune specification n'est ecrite. On passe directement a l'implementation, et on fait confiance aux utilisateurs pour decouvrir les bugs et les corriger.
Les outils de verification formelle peuvent etre tres utiles pour les systemes paralleles et temps reel. On peut ainsi verifier des proprietes telles que:
- La requete de X est toujours satisfaite avant 20 secondes
- Un dead-lock ne peut jamais survenir
- Toute requete est satisfaite en un temps fini
Notez bien que l'on verifie, c'est plus puissant qu'un test. Verifier revient a tester toutes les possibilites.
Un peu de pub: http://www.uppaal.com/(...) Uppaal Un outil de verification de systemes temps reels concurrents http://www.atelierb.societe.com/(...) Atelier B Une methode et des outils pour generer du code correct http://www.afm.sbu.ac.uk/(...) Formal methods Pour ceux qui veulent en savoir plus sur les methodes formelles. C'est un domaine de recherche tres actif en ce moment.
[...] cela renverrait la responsabilité sur le propriétaire (qui n'a qu'à verrouiller sa machine proprement: Si un cambrioleur vous vole alors que vous avez laissé votre maison ouverte, il n'y aura ni effraction, ni dédomagement)
Pas de dédomagement, certes, mais le fait d'entrer dans une propriété privée sans y être autorisé reste un délit, non ?
stp, à moins que tu n'écrives de la poésie, n'insère des retours à la ligne qu'à chaque fin de paragraphe. Le retour à la ligne en bout de ligne se fait automatiquement. Ca rendra la lecture de ton texte beaucoup plus facile.
-1, parceque c'est pas genial comme sujet de débat
Je ne dirais pas que la radiosite est meilleure que le ray-tracing. Le ray-tracing est genial pour la reflection et la transparence, la radiosite pour l'illumination globale. D'ailleurs, je parlerais plutot de diffusion dans le cas de la radiosite, pas de reflection.
Suivant le type de scene, l'un ou l'autre est a choisir.
On peut aussi utiliser une combinaison de ray-tracing et de radiosite, les resultats peuvent etre impressionnants.
Si B ou C ont une amelioration a apporter a l'idee de A, ils peuvent breveter cette amelioration (tant que cette amelioration est un procede innovant et apporte quelque chose a l'idee de A).
Le probleme est bien la. L'amelioration en elle meme est souvent une idee deja utilisee dans d'autres domaines. En plus, avant de se lancer dans une eventuelle recherche pour ameliorer, on ne sait pas si l'amelioration sera garantie d'etre brevetable.
Cependant, les entreprises pour rendre la R&D rentable ont besoin des brevets pour s'assurer un certain retour sur investissement. Je vois mal une compagnie quelconque investir dans la R&D si c'est juste pour le bien de l'humanite. La R&D coute cher et doit etre rentabilisee. A moins bien sur que - comme cite plus bas - dans notre monde utopiste les chercheurs ne soient pas payes a l'instar des professeurs...
La recherche, c'est aussi une affaire de collaboration. Quand A trouve une idee, il n'est pas rare que B, C... y pensent et ameliorent l'idee de A. Si le moteur principal de la recherche est effectivement la popriete exclusive (offerte par les brevets) permettant l'exploitation, quel interet auront alors B et C a ameliorer l'idee de A ? En effet, A ayant deja un brevet, B ou C ne pourront pas deposer de brevet pour proteger leurs ameliorations, et n'ont donc aucun interet a ameliorer l'idee de A.
Conclusion: les brevets peuvent etre un obstacle a l'avancee de la science.
Il faut certes remunerer les gens qui ont des idees. Le capitalisme s'est averee etre un moyen assez efficace de remunerer les efforts des gens. Faut-il en conclure que les brevets, application de la logique capitaliste aux idees, sont la meilleure solution ? Les idees ne sont pas des biens, et la solution du capitalisme n'est a mon avis pas bonne.
Les problemes que je rencontre avec ReiserFS ne lui sont pas vraiment imputables. J'attendais de ReiserFS qu'il ne corrompe pas mes donnees lors d'un crash, alors qu'il n'a jamais pretendu le faire.
A partir du moment ou ta machine ne se plante pas, reiserFS a sans doute ses avantages (rapidite ?).
Mais a ceux qui comme moi veulent eviter de perdre leurs fichiers a cause de coupures/plantages, reiserFS n'est apparemment pas l'ideal.
Pour les donnees sures, mon experience recente indique que reiserFS n'est pas la panacee.
J'avais fait l'operation de passer d'ext2 en reiserFS, je vais la reiterer pour aller de reiserFS en ext3.
Et tu n'es pas en droit de me demander de te le donner gratuitement, je suis dans l'obligation de te dire ou tu pourrais le trouver gratuitement, ce qui n'est pas tout a fait pareil.
Meme pas. La GPL interdit de vendre separement les sources et les binaires. Mais rien ne t'oblige a dire "Je vends mes binaires+sources pour 300 balles, mais tu peux les avoir gratos sur ..."
Bof, entre MS et Nintendo, y'a pas d'enorme difference. Autant que je sache, Nintendo n'encourage pas les LL.
La XBox est peut-etre meme plus accessible pour les bidouilleurs. Le matos est connu, et l'environnement de developpement doit pas etre bien different de celui pour les jeux PC.
Ecrire des progs pour sa GC, ca doit pas etre facile, par contre.
Tant qu'a faire, je prefere la console de salon de Nokia: http://www.ostdev.net/(...)
[Les journalistes] se font l'avocat du diable
Ben oui, et ou est le probleme ? Quand on veut inviter quelqu'un a defendre ses idees, il faut bien attaquer les idees en question, non ?
Si on cherche a eviter tous les ecueils lors d'une interview, on obtient un entretien plat, du genre de ceux auxquels on peut assister lors d'evenements sportifs.
Par exemple sur "vivre du libre". La c'est juste prendre les arguments à 2 balles des anti-libre pour l'énerver avec une question dont la réponse a été explicitement donnée avant. Il aurait pu dire la meme chose mot pour mot.
Je ne trouve pas que la reponse a ete explicitement donnee avant. La question est interessante, elle est regulierement posee, et il n'existe pas de reponse simple (apparemment). Ici, RMS repond qu'il s'en fiche. Il ne l'a jamais dit mot pour mot avant.
Non, il n'y a pas d'interdiction, il dit que c'est immoral.
Seuls les gens qui font les lois peuvent interdire. RMS ne fait pas les lois, donc il n'interdit pas. C'est vrai. N'empeche qu'il souhaiterait que ca soit interdit. Ou alors RMS souhaite vivre dans un monde immoral. La difference est donc tenue.
Mais quand il y a de l'incompétence ou de la mauvaise foi dans les questions, je ne vois pas au nom de quoi il serait interdit d'en parler.
Je ne t'interdis pas d'en parler. Simplement, je dis ce que je pense de l'interview, pas si mauvaise a mon avis.
-1 parceque notre discussion ne resoudra pas le probleme de la faim dans le monde...
Non, Linus aussi defend le partage de l'information. Maintenant que Linux est devenu un truc qui rapporte de l'argent, il ne lui viendrait pas a l'idee de fermer les sources, meme s'il le pouvait.
Le commentaire de RMS sur Linus m'a assez etonne. Linus s'exprime sans doute moins sur le sujet que RMS, mais je pense que l'attirance de Linus pour l'ideologie du libre ne peut pas etre remise en cause.
Enfin, le mieux serait de demander a Linus, mais je suis sur qu'il ignorerait la question, jugee sans interet.
Linus est simplement plus pragmatique que RMS, il accepte l'existence du logiciel proprietaire. Aux yeux de RMS, ca suffit pour dire que Linus n'a jamais embrasse la philosophie du libre.
A mon avis, tu viens juste d'enoncer un argument en faveur de l'appelation GNU/Linux. Si on veut faire la distinction entre toutes les variantes de Linux, il faut bien leur donner des noms differents. Le nom GNU/Linux pour le systeme que nous connaissons tous n'est finalement pas mauvais. Le jour ou MS sortira un OS base sur le noyau Linux avec leurs softs par-dessus, on pourra appeler ce soft MS/Linux 2023.
Ca n'est pas de l'incompetence. Ce genre de question "piege" permet de verifier la coherence de la personne interrogee. RMS aurait pu repondre et se contredire. Il ne l'a pas fait, heureusement pour lui.
D'autre part, la question souligne que l'avis de RMS a des consequences facheuses pour les developpeurs. On veut leur interdire d'imposer des licences contraignantes. Il s'agit bien d'une limitation de leur liberte, et ca merite d'etre souligne. Ce que fait la question.
Critiquer les journalistes, c'est facile. Trouver les bonnes questions a poser, c'est beaucoup plus dur. Tu penses que tu aurais fait mieux ?
A propos du communisme: l'idee peut etre attirante par certains aspects (l'argent n'est plus une fin en soi), mais elle pose des problemes. Pourquoi se fatiguer a faire un programme super bon si on peut gagner autant d'argent avec un programme moyen ?
Il faut une autre motivation, qui existe dans le LL, a savoir le plaisir de faire son boulot correctement, la reconnaissance... Mais est-ce suffisant ?
Le probleme existe aussi dans un systeme capitaliste quand une societe est en position de monopole. La societe n'a pas besoin d'ameliorer son produit, vu qu'elle ne gagnera pas plus d'argent.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . En réponse à la dépêche Darwin et Linus. Évalué à 1.
Il se trouve que le developpement de Linux suit un peu le modele de la recherche. Il est parti d'un modele existant, Unix, mais le but est bien de faire mieux, meme si ca implique de se demarquer du modele original.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . En réponse à la dépêche Darwin et Linus. Évalué à 1.
L'idee de Linus consistant a "partir dans toutes les directions et garder la meilleure" marche bien pour Linux, parcequ'il n'y a pas de limites sur le nombre de developpeurs et testeurs (enfin presque). Mais Linux est un cas bien a part de projet libre.
Pour le reste du logiciel, a savoir le logiciel proprietaire developpe par une dizaine de programmeurs, il est essentiel de gagner en efficacite. Le design est une tentative dans cette direction, et l'experience tendrait a montrer que c'est une bonne idee. Le gain en efficacite passe en general par la reduction du chaos.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . En réponse à la dépêche Darwin et Linus. Évalué à 1.
En plus, l'architecte changeait plusieurs fois, et chaque nouvel architecte apportait sa propre touche. En general, on peut meme le remarquer, dans la mesure ou de nombreuses cathedrales melangent les styles. Ca va plus loin que la decoration, il y a meme des fois ou des "extensions" sont rajoutees apres coup (une tour suplementaire, par exemple).
Nombre de cathedrales ont ete partiellement detruites (incendies, guerre) et reconstruites en suivant une nouvelle orientation.
Pour moi, une cathedrale est plutot un exemple de "conception a geometrie variable".
Autre exemple: les caravelles. J'ai appris cet ete qu'elles etaient construites sans plan general, sans calcul. Certes, ca a eu des consequences, dans la mesure ou certaines coulaient peu apres leur mise a flot. Mais globalement, elles ont permis la mise au point des navires actuels. Si les concepteurs de l'epoque s'etaient emmelles les pinceaux dans le processus de realisation d'un plan qu'il ne pouvait maitriser, les navires ne seraient sans doute pas ce qu'ils sont aujourd'hui.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . En réponse à la dépêche Darwin et Linus. Évalué à 1.
Quand tu cites "tous les gros projets reussis ont ete realise sans design", tu fais peut-etre reference a ce passage:
Linus ne dit pas la que le design ne sert a rien, il dit juste qu'il ne faut pas se fixer sur la theorie apprise a l'ecole. De plus, il parle ici uniquement d'une partie du logiciel (celui qui ne se limite pas a une niche).
L'argumentation de Linus, telle que je la comprends est la suivante:
- La planification detaillee n'est pas indispensable. Exemple: l'evolution
- Dans le cas du logiciel, une planification a long terme est nefaste. Exemples: 1. Les logiciels de SUN se cantonnent a une niche (SUN etant le champion de la planification a long terme) et vont bientot disparaitre (c'est sa prevision, pas la mienne, hein!) . 2. Ceux qui disent que Linux est le resultat d'une planification a long terme ont tort. On peut le croire, il doit savoir de quoi il parle.
[^] # Re: Design et Invention
Posté par Johann Deneux . En réponse à la dépêche Darwin et Linus. Évalué à 1.
Et moi je suis contre. La notion de beaute est tres sujective, c'est bien connu. Surtout quand on parle de code. Sortir un morceau de code de son contexte et dire c'est laid, c'est facile.
100% des programmeurs que je connais (y compris moi) pensent qu'ils sont des programmeurs propres. A se demander pourquoi il y a autant de code sale.
Qu'on rale apres ceux qui ne suivent pas les conventions de codage, c'est normal. Mais si tous ceux qui tombent sur un morceau de code "sale" devaient se plaindre, on en finirait plus.
[^] # Tordons le cou aux coups bas des coûts trop hauts
Posté par Johann Deneux . En réponse à la dépêche Microsoft trop cher pour le gouvernement britannique. Évalué à 1.
[^] # Re: En parlant de nombre
Posté par Johann Deneux . En réponse à la dépêche interdiction de diffuser DeCSS. Évalué à 1.
Pire encore, je pense qu'un algorithme generant un nombre univers ne peut pas etre encodable par quelquechose de "plus petit" qu'un nombre univers.
Ouf, l'innovation est sauve ;)
Un mathematicien est-il present dans la salle pour confirmer/infirmer mes delires ?
[^] # Re: En parlant de nombre
Posté par Johann Deneux . En réponse à la dépêche interdiction de diffuser DeCSS. Évalué à 1.
En continuant avec les nombres, il me semble qu'il existe des nombres "univers" qui codent toute information imaginable (et inimaginable aussi).
Autrement dit, il existe un nombre qui contient la declaration des droits de l'homme, la Bible et le Coran, toutes vos conversations telephoniques, les reponses a toutes les questions et... toutes les innovations technologiques.
Je ne sais pas si on connait un algorithme pour generer un tel nombre, mais si c'est le cas, celui qui le trouve a interet a deposer un brevet dessus. Toute decouverte posterieure n'en sera plus une, et des royalties devront etre versees...
[^] # Re: FBI = spy machine ?
Posté par Johann Deneux . En réponse à la dépêche magic lantern : le troyen du F.B.I. Évalué à 1.
[^] # Re: C'est quoi un langage de vérification ?
Posté par Johann Deneux . En réponse à la dépêche Jeda: langage de vérification open source. Évalué à 1.
Le schema de developpement d'un logiciel actuel est le suivant:
1. Etude des besoins
2. Conception du logiciel
3. Implementation
4. Tests
5. Suivant les resultats des tests, retour en 2 ou 3.
Avec verification:
1. Etude des besoins
2. Conception informelle
3. Ecriture d'une specification formelle
4. Implementation
5. Verification
6. Retour en 4.
Le point important est l'etape 3. On ecrit dans un langage mathematique ce que le code doit faire. A partir de ca, on peut verifier que l'implementation respecte la specification.
Dans le cas de jeda, ce n'est pas de la verification qui est faite, mais plutot du test. A partir de la specification, on genere les tests pour tester que le programme est correct.
Un petit exemple:
Specification: f est un fonction de N dans N tel que: pour tout n>0, f(n) est pair.
Implementation:
int f(int n) {
return 2*n;
}
Tester revient a regarder la valeur de f(n) pour 1000 n differents (par exemple).
Une verification analyse le code source, et prouve que toute valeur retournee par f est pair. Ici c'est "evident", vu qu'un entier positif multiplie par 2 est toujours pair (il y a un piege, cependant, la fonction ne manipule qu'un sous-ensemble des entiers)
Traditionnellement (pour la plupart des LL, par exemple), aucune specification n'est ecrite. On passe directement a l'implementation, et on fait confiance aux utilisateurs pour decouvrir les bugs et les corriger.
Les outils de verification formelle peuvent etre tres utiles pour les systemes paralleles et temps reel. On peut ainsi verifier des proprietes telles que:
- La requete de X est toujours satisfaite avant 20 secondes
- Un dead-lock ne peut jamais survenir
- Toute requete est satisfaite en un temps fini
Notez bien que l'on verifie, c'est plus puissant qu'un test. Verifier revient a tester toutes les possibilites.
Un peu de pub:
http://www.uppaal.com/(...) Uppaal Un outil de verification de systemes temps reels concurrents
http://www.atelierb.societe.com/(...) Atelier B Une methode et des outils pour generer du code correct
http://www.afm.sbu.ac.uk/(...) Formal methods Pour ceux qui veulent en savoir plus sur les methodes formelles. C'est un domaine de recherche tres actif en ce moment.
[^] # Re: Il ya trois choses qui me chagrinent:
Posté par Johann Deneux . En réponse à la dépêche Dispositions européennes sur la cybercriminalité. Évalué à 1.
Pas de dédomagement, certes, mais le fait d'entrer dans une propriété privée sans y être autorisé reste un délit, non ?
[^] # Re: Les problèmes de retours à la ligne
Posté par Johann Deneux . En réponse à la dépêche KDE 2.2.1 sous Windows. Évalué à 0.
-1, parceque c'est pas genial comme sujet de débat
[^] # Re: À propos de POV-Ray
Posté par Johann Deneux . En réponse à la dépêche Un nouveau magazine dédié au graphisme numérique. Évalué à 1.
Suivant le type de scene, l'un ou l'autre est a choisir.
On peut aussi utiliser une combinaison de ray-tracing et de radiosite, les resultats peuvent etre impressionnants.
[^] # Re: En gros...
Posté par Johann Deneux . En réponse à la dépêche Conférence sur la Propriété intellectuelle. Évalué à 1.
Le probleme est bien la. L'amelioration en elle meme est souvent une idee deja utilisee dans d'autres domaines. En plus, avant de se lancer dans une eventuelle recherche pour ameliorer, on ne sait pas si l'amelioration sera garantie d'etre brevetable.
[^] # Re: En gros...
Posté par Johann Deneux . En réponse à la dépêche Conférence sur la Propriété intellectuelle. Évalué à 1.
La recherche, c'est aussi une affaire de collaboration. Quand A trouve une idee, il n'est pas rare que B, C... y pensent et ameliorent l'idee de A. Si le moteur principal de la recherche est effectivement la popriete exclusive (offerte par les brevets) permettant l'exploitation, quel interet auront alors B et C a ameliorer l'idee de A ? En effet, A ayant deja un brevet, B ou C ne pourront pas deposer de brevet pour proteger leurs ameliorations, et n'ont donc aucun interet a ameliorer l'idee de A.
Conclusion: les brevets peuvent etre un obstacle a l'avancee de la science.
Il faut certes remunerer les gens qui ont des idees. Le capitalisme s'est averee etre un moyen assez efficace de remunerer les efforts des gens. Faut-il en conclure que les brevets, application de la logique capitaliste aux idees, sont la meilleure solution ? Les idees ne sont pas des biens, et la solution du capitalisme n'est a mon avis pas bonne.
[^] # Re: reiser et meta
Posté par Johann Deneux . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
A partir du moment ou ta machine ne se plante pas, reiserFS a sans doute ses avantages (rapidite ?).
Mais a ceux qui comme moi veulent eviter de perdre leurs fichiers a cause de coupures/plantages, reiserFS n'est apparemment pas l'ideal.
[^] # Re: reiser et meta
Posté par Johann Deneux . En réponse à la dépêche Les noyaux Linux nouveaux sont parmi nous. Évalué à 1.
J'avais fait l'operation de passer d'ext2 en reiserFS, je vais la reiterer pour aller de reiserFS en ext3.
[^] # Re: Au sujet des licences Open Source/Libre
Posté par Johann Deneux . En réponse à la dépêche Lecteur de divx: la GPL violée par des développeurs Russes. Évalué à 1.
Meme pas. La GPL interdit de vendre separement les sources et les binaires. Mais rien ne t'oblige a dire "Je vends mes binaires+sources pour 300 balles, mais tu peux les avoir gratos sur ..."
[^] # Re: Y'a pas 50 solutions
Posté par Johann Deneux . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 6.
[^] # Re: Ah, un petit espoir ?
Posté par Johann Deneux . En réponse à la dépêche Ventes XBOX et NGC aux Etats-Unis. Évalué à 8.
La XBox est peut-etre meme plus accessible pour les bidouilleurs. Le matos est connu, et l'environnement de developpement doit pas etre bien different de celui pour les jeux PC.
Ecrire des progs pour sa GC, ca doit pas etre facile, par contre.
Tant qu'a faire, je prefere la console de salon de Nokia:
http://www.ostdev.net/(...)
[^] # Re: On mets le doigt où ca fait mal ...
Posté par Johann Deneux . En réponse à la dépêche Courte interview de Richard Stallman. Évalué à 0.
Ben oui, et ou est le probleme ? Quand on veut inviter quelqu'un a defendre ses idees, il faut bien attaquer les idees en question, non ?
Si on cherche a eviter tous les ecueils lors d'une interview, on obtient un entretien plat, du genre de ceux auxquels on peut assister lors d'evenements sportifs.
Par exemple sur "vivre du libre". La c'est juste prendre les arguments à 2 balles des anti-libre pour l'énerver avec une question dont la réponse a été explicitement donnée avant. Il aurait pu dire la meme chose mot pour mot.
Je ne trouve pas que la reponse a ete explicitement donnee avant. La question est interessante, elle est regulierement posee, et il n'existe pas de reponse simple (apparemment). Ici, RMS repond qu'il s'en fiche. Il ne l'a jamais dit mot pour mot avant.
Non, il n'y a pas d'interdiction, il dit que c'est immoral.
Seuls les gens qui font les lois peuvent interdire. RMS ne fait pas les lois, donc il n'interdit pas. C'est vrai. N'empeche qu'il souhaiterait que ca soit interdit. Ou alors RMS souhaite vivre dans un monde immoral. La difference est donc tenue.
Mais quand il y a de l'incompétence ou de la mauvaise foi dans les questions, je ne vois pas au nom de quoi il serait interdit d'en parler.
Je ne t'interdis pas d'en parler. Simplement, je dis ce que je pense de l'interview, pas si mauvaise a mon avis.
-1 parceque notre discussion ne resoudra pas le probleme de la faim dans le monde...
[^] # Re: Vieux rancunier...
Posté par Johann Deneux . En réponse à la dépêche Courte interview de Richard Stallman. Évalué à 1.
Le commentaire de RMS sur Linus m'a assez etonne. Linus s'exprime sans doute moins sur le sujet que RMS, mais je pense que l'attirance de Linus pour l'ideologie du libre ne peut pas etre remise en cause.
Enfin, le mieux serait de demander a Linus, mais je suis sur qu'il ignorerait la question, jugee sans interet.
Linus est simplement plus pragmatique que RMS, il accepte l'existence du logiciel proprietaire. Aux yeux de RMS, ca suffit pour dire que Linus n'a jamais embrasse la philosophie du libre.
[^] # Re: Hallucinant...
Posté par Johann Deneux . En réponse à la dépêche Courte interview de Richard Stallman. Évalué à 1.
[^] # Re: On mets le doigt où ca fait mal ...
Posté par Johann Deneux . En réponse à la dépêche Courte interview de Richard Stallman. Évalué à 0.
D'autre part, la question souligne que l'avis de RMS a des consequences facheuses pour les developpeurs. On veut leur interdire d'imposer des licences contraignantes. Il s'agit bien d'une limitation de leur liberte, et ca merite d'etre souligne. Ce que fait la question.
Critiquer les journalistes, c'est facile. Trouver les bonnes questions a poser, c'est beaucoup plus dur. Tu penses que tu aurais fait mieux ?
[^] # Re: avis perso
Posté par Johann Deneux . En réponse à la dépêche Courte interview de Richard Stallman. Évalué à 1.
Il faut une autre motivation, qui existe dans le LL, a savoir le plaisir de faire son boulot correctement, la reconnaissance... Mais est-ce suffisant ?
Le probleme existe aussi dans un systeme capitaliste quand une societe est en position de monopole. La societe n'a pas besoin d'ameliorer son produit, vu qu'elle ne gagnera pas plus d'argent.