Papa Torvalds prend la théorie de l'évolution en exemple pour montrer que le design ne sert à rien dans un projet. Selon lui, Linux n'a jamais été pensé à l'avance. Le contraire l'aurait conduit à l'échec. C'est le cas de tous les gros projets réussis (l'homme :-), etc. Cette philosophie explique pourquoi Linus n'est pas indispensable (sauf par son côté sociable). Ce qui fait le sel de la discussion, c'est qu'on peut l'appliquer à d'autres domaines, comme le résumait Alan Cox: "on a fait des murs avant de réfléchir sur le ciment".
Aller plus loin
- Le débat (2 clics)
- Le thread sur Slashdot (2 clics)
# Thread complet
Posté par Jean-Yves B. . Évalué à 1.
http://marc.theaimsgroup.com/?l=linux-kernel&m=100699054912067&(...)
Ce n'est pas précisément le message de départ mais quand-même. Le plus drôle c'est que c'est un message appelant à laisser tomber le délire qui l'a généré en fait :)
C'est dur, pour rire une fois de temps en temps il faut suivre 2e30 mailing-lists ... :)
[^] # Re: Thread complet
Posté par Obsidian . Évalué à 1.
En gros, c'est le travail des gens du Zapping !
# Mefiez vous
Posté par Fabimaru (site web personnel) . Évalué à 1.
# hum ...
Posté par Yves Dessertine . Évalué à 1.
Hum... il y a des jours je me demande :-).
-1
[^] # Re: hum ...
Posté par VACHOR (site web personnel) . Évalué à 1.
La preuve, Windows n'a pas encore disparu, cette espèce à la vie très coriace gêne l'envolée de la nouvelle génération de software.
Il faudra probablement une grosse météorite pour provoquer l'extinction des kro$softsaures ;-)
[^] # Re: hum ...
Posté par koopa . Évalué à 1.
- habitat propice: tous les matériels et périphériques sont prévus pour lui
- nourriture abondante: la plupart des logiciels existent pour lui et parfois uniquement pour lui
- espèce très prolifique : très facile à pirater, pas la peine d'un pitate expérimenté pour monter un élevage chez soi.
- s'adapte à tous les climats (traduit dans toutes les langues), dans tous les milieux : consoles, serveurs, PocketPC, ordinateurs de bureau
- espèce séduisante pour l'oeil (mais sa chair a mauvais gout) mais c'est trop tard tu as déjà payé.
- évolue assez rapidement pour ne pas se faire détruire par les de nouvelles espèces qui pourrait apparaitre autres espèces car Microsoft sait
racheter ses concurrentsfaire marche arrière en cas de Besoin (ex MSN en 95)- aucun prédateur connue, donc le fait qu'il ait une jambe plus courte que l'autre ne le gène pas trop pour survivre.
En fait Microsoft c'est la "Taxifolia" de l'informatique.
la taxifolia est une algue verte qui est en train de recouvrir le fond de la Méditerrannée et qui fait asphyxie les poissons et les végétaux marins.
Microsoft est loin d'être un dinosaure ou une espèce anachronique comme peuvent l'être Apple et Novell. C'est une
maladieentreprise étonnament moderne.[^] # Re: hum ...
Posté par Anonyme . Évalué à 1.
Cela dit, une espèce qui a tout pour réussir, peut disparaître : regarde les dinosaures, une météorite, et hop, plus rien...
[^] # Re: hum ...
Posté par Olivier M. . Évalué à 1.
De plus les dinosaures n'avaient peut-être pas tant que ca "tout pour réussir". Il leur manquait une faculté d'adaptation à court terme (c'est que ca coûte cher à changer ces gros machines la, ma bonne dame), et surtout ils étaient "en maîtres".
On pourrait peut-être en tirer que le meilleur moyen de descendre une boîte, c'est de la conforter dans sa position et d'attendre qu'endormie sur ses lauriers elle commette une grosse erreur (qui a dit "XP"?)
# faute / pas faute?
Posté par Marc (site web personnel) . Évalué à 1.
Faute pas faute?
[^] # Re: faute / pas faute?
Posté par Philip Marlowe . Évalué à 1.
-1 : si on reprend toutes les fautes d'orthographe, on n'est pas rendu. Quand je me relis, je vois que j'en laisse passer, et je suis pourtant susceptible à ce sujet.
[^] # Re: faute / pas faute?
Posté par Philip Marlowe . Évalué à 1.
# ce qui reste à voir
Posté par Anonyme . Évalué à 1.
Je ne suis pas entièrement convaincu. Car si « on a fait des murs avant de réfléchir sur le ciment », je doute qu'on ait fait des tours eiffel et cathédrales sans « design » et dans le cas des batiments en ciment, j'aurai peu confiance s'il n'y avait pas plusieurs batteries d'ingénieurs pour les concevoir...
Allez dire aux Japonais que le « design » ne sert à rien dans le construction de leurs batiments resistants aux tremblement de terre fréquents qu'ils subissent...
[^] # Re: ce qui reste à voir
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
L'informatique et la programmation sont plus dans un stade "artisanal" je pense. Bien sûr, il existe des méthodologies, des algorithmes connus, etc. , mais bon... on ne peut pas dire que leur adoption soit encore universelle.
Bref, ce que je veux dire, c'est que puisqu'il n'existe pas de méthodologies absolues pour faire un bon logiciel, pouvoir réaliser l'implémentation de solutions différentes pour les "détails" du projet, sans avoir une idée arrêtée sur le design du projet global, ne peut que favoriser la robustesse et la qualité de l'ensemble.
C'est une méthode difficilement applicable en entreprise (encore qu'elle le soit en partie sur certaines applications critiques comme l'aviation), mais dans le cas des LL, c'est possible (presque inhérent d'ailleurs), alors autant en profiter.
[^] # Re: ce qui reste à voir
Posté par Anonyme . Évalué à 1.
A priori, c'est bien le developpement de méthodes qui à caractérisé l'évolution technique. Par exemple, même si « la medecine empirique » à un intérêt, peu être efficace, c'est pas pour autant que les avancées dans le domaine de la médecine officielle sont négligeables...
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . É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: ce qui reste à voir
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Dans ce sens, oui, je pense que tous les gros projets réussis ne sont pas issus d'une méthode type "je me prends la tête pour faire des specs et ensuite j'implèmente ces specs sans rien changer" mais plutôt "je design un truc, je teste, je change ou fait éventuellement évoluer le tout".
[^] # Re: ce qui reste à voir
Posté par spim . Évalué à 1.
Ayant passe pas mal de temps a retaper des programmes codes a la porcasse, je leur prefere largement ceux qui ont ete code avec un minimum de reflexion derriere.
Du style quand l'ajour de fonctionnalites a ete prevu ca evite de casser une bonne partie du code pour faire quelque chose d'evolutif.
Maintenant si certains preferent refaire le code tout les 3 mois ...
[^] # Re: ce qui reste à voir
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: ce qui reste à voir
Posté par spim . Évalué à 1.
Apres etre passe par ma periode ASM, j'ai pris l'habitude de penser mon logiciel mais aussi de penser son evolution, et je pense pouvoir dire que cela ameliore de beaucoup la maintenance.
De plus quand une boite voit que ses mises a jour et sa maintenance sont moins lourdes, elle ont tendance a etre plus confiantes et a proposer plus de projects etant donne qu'il reste un peu plus de fric dans le budget.
Dans le monde du libre la situation est pire, car il y a peu de personnes pour gueuler si la qualite du code ainsi que de sa structuration sont mediocres, il n'y a qu'a voir le nombre de projets qui sont obliges de refondre une grosse partie du code assez souvent.
[^] # Re: ce qui reste à voir
Posté par imr . Évalué à 1.
D'ailleurs la direction "la fléche de plus en plus haute - c'est moi ké la plus haute - i am ze king of ze woooorrld" s'est arrétée naturellement et pas parce que le design le prévoyait.
Pareil pour la direction "on met plein de bois partout pour les charpentes - on mettra des panneaux interdits de fumer ca suffira".
Pour pousser plus loin la référence "cathédrale", le design "je m'en fous de la sécurité - suffit de faire passer des lois à la con" s'arrétera naturellement aussi, si une réaction intelligente n'a pas lieu avant.
[^] # Re: ce qui reste à voir
Posté par imr . Évalué à 1.
arghh un lapsus révélateur ...
...sur internet
...10 ans de psychanalyse foutu en l'air ...
[^] # Cathédrales
Posté par darkleon (site web personnel) . Évalué à 1.
Faux, c'est justement parce qu'à les connaissances nécessaires pour faire de flêches plus hautes n'éxistaient pas que la course à la flêche la plus haute s'est arrêté. La conception et la connaissance de la résistance des matériaux de l'époque rendait l'netreprise impossible (sans parler du finnancement astronomique pour un projet "extréme").
Donc le design à forcé l'arrêt de la course aux cathédrales, car on pouvait estimer soit la faisabilité du projet, soit son coût qui rendait le projet tout autant caduc.
[^] # Re: Cathédrales
Posté par Anonyme . Évalué à 1.
Donc une situation politique et philosophique plutôt défavorable à la poursuite de ce type de constructions.
[^] # Re: Cathédrales
Posté par imr . Évalué à 1.
Tu ne contredis pas du tout ma phrase.
La course à la fléche la plus haute s'est arrétée quand la fléche de ("euh" vérifier, je ne suis pas sur lâ) Strasbourg s'est cassée la gueule.
c'est ce que j'appelle un coup d'arrét naturel.
Le projet était de faire des cathédrales partout dans chaque ville. Quand ils sont partis dans la direction "charpentes en bois", des incendies les ont fait obliqué mais le projet a continué.
Quand ils ont eu la manie "ma fléche est plus haute que la tienne" , méme motif même sanction (marrant d'ailleurs, ils avaient pas du lire le passage "tour de babel").
Si le dessin avait été qu'une cathédrale ait une fléche toujours plus haute que la précedente, n'ayant pas "les connaissances nécessaires pour faire de flêches plus hautes", le projet aurait arrété à ce moment la. Or il a continué mais avec des fléches de taille raisonnable.
Pas de contradiction avec ce que je disais. Pas de contradiction avec les commentaires de Linus Throvalds.
Ils avaient un projet en cours de faire des cathédrales mais pas de design a priori de ce qu'est une cathédrale donc la possibilité de passer outre toutes les difficultés en s'adaptant et en modifiant leur conception de l'objet du projet.
[^] # Cathédrales du bazar (-oo car HS)
Posté par darkleon (site web personnel) . Évalué à 1.
Bon on va faire comme dans l'école des fans, tout le monde à gagné.
Ah et désolé pour les fautes de mon post précedent, et pourtant je n'étais pas sous l'ffet de substances psychotropes.
-1 car HS
[^] # Cathédrales du bazar (-oo car HS)
Posté par darkleon (site web personnel) . Évalué à 1.
Bon on va faire comme dans l'école des fans, tout le monde à gagné :-)
Ah et désolé pour les fautes de mon post précedent, et pourtant je n'étais pas sous l'effet de substances psychotropes.
-1 car HS
[^] # Re: ce qui reste à voir
Posté par Christophe --- . Évalué à 1.
Ayant la (mal)chance de comprendre un peu l'anglais, j'ai lu le thread en anglais avant d'avoir la nouvelle sur linuxfr. Et, en tombant sur cette nouvelle, justement, j'ai eu l'impression que le contenu du thread n'était pas retranscrit honnetement. Mais j'arretes de palabrer, et j'explique :
- en effet, linux torvalds compare l'évolution des logiciels à celle de l'évolution naturelle. Chose que l'on ne peut faire pour le materiel, à cause de son état figé.
- "Selon lui, Linux n'a jamais été pensé à l'avance. Le contraire l'aurait conduit à l'échec." nous dit la nouvelle. Ce n'est pas exactement ce que nous dit linus. Il nos explique que le fait que linux ait été conçu sans but a atteindre nous à amener à un système qui est partis dans plusieurs directions, et qui ainsi lui à permis d'aller vers plusieurs domaines. Le choix d'une fonction finale ne l'aurait certainement pas conduit à l'echec, mais il ne serait par exemple que devenu un unix classique, peut-etre le meilleur, mais n'aurait pas apporté tous ces boulversement au monde unix, tel que par exemple l'avancée en multimédia, la possibilité d'en faire en système embarqué, que ce soit dans un calculateur ou un PDA, tout en etant utilisable à la fois en bureautique et en sciences par exemple.
- enfin, la citation d'Alan Cox, n'est pas exacte : "on a fait des murs avant de réfléchir sur le ciment" : ce n'est pas exactement ce qu'il dit, puisqu'il ne parle pas du ciment, mais de sa composition chimique. Quand nos ancetres ont construits leurs maisons et cathédrales, ils n'avaient pas la moindre idée de la composition du ciment. Ils ont utilisés celui qui, par expérience (le "test & see"...) celui qui leur semblait le plus solide. Et puis on ne parle pas de tous ces batiments qui se sont écroulés à l'époque, peut-être parceque devant les ruines nos ancêtres savaient déjà tirer les leçons des erreurs et reconstruire...
Enfin, j'aimerais tempérer ton commentaire pour ajouter ceci : il est vrai que maintenant l'on emploi de nombreux ingénieurs à la tache, pour effectuer nombre de calculs pour les choix de matériaux, mais il faut relativiser : les cathédrales sont "trops solides" par rapport à ce que l'on ferait de nos jours, car les calculs sont fait principalement par péché d'avarice, afin d'obtenir la solidité nécéssaire tout en baissant le coup de fabrication. (heureusement, ce n'est pas le cas partout :))
[^] # Re: ce qui reste à voir
Posté par Anonyme . Évalué à 1.
C'est vrai, la logique économique n'est plus similaire. Cela dit, aujourd'hui, on comprend mieux ce qu'on construit.
Même si rien n'est parfait, on a tendance à savoir ce qu'on doit construire pour supporter un tremblement de terre, 10 personnes dans un ascenceur.
Pour la resistance aux avions, c'est pas encore gagné.
Enfin ton éclaircissement vaux le coup :)
Pour l'histoire du ciment, c'est ainsi que j'avais plus ou moins interpreté la chose.
Enfin, la question que pose Cox est ambigue : en fait, nos ancêtres avait pas les connaissances que nous avons sur le ciment. Structure atomique, etc.. ils ne connaissaient pas. Ils n'avaient pas de labos pour faire des tests. Cela dit, il produisait tout de même et choisissait bien leurs matériaux puisqu'un certains nombres de leurs ouvrages leurs ont largement survécu.
Donc en fait, on ne peut pas dire qu'ils ne savaient pas ce qu'ils faisaient ni réellement vers où ils allaient. Et si l'on observe des constructions antiques (parce qu'on ne parle pas de préhistoire, si on parle de murs, on parle forcement de peuplades sédentarisées), le colisée de Rome, l'acropole d'Athènes, sont des sacré témoignages de constructions méthodiques...
Alors finalement, je trouve le propos de Cox relativement creux :
Certes ils n'avaient pas une connaissance aussi complète que la notre sur les matériaux qu'ils utilisaient. Néanmoins, ils avaient un but, ce n'était pas du bricolage au petit bonheur la chance nécessairement.
Probablement que Cox voulait simplement dire que l'informatique en est encore à ses débuts et que comme aux débuts de la construction/maçonnerie, la connaissance empirique reste la règle générale.
C'est ce qui parait le plus cohérent.
Mais c'est mal exprimé et du coup mal interprété (et difficilement interpretable).
[^] # Re: ce qui reste à voir
Posté par jbcombes . Évalué à 1.
Avant de pouvoir faire ces calculs, c'etait beaucoup test&see... et dans le batiment, plusieurs siècles d'experiences (parfois catastrophiques)
En informatique, on en est encore aux débuts. Il existe déjà des methodes de conception pour certains domaines, mais pas tout... Hors de ces sentiers balisés, pas de réel design. Ou plutot un design à géometrie variable...
[^] # Re: ce qui reste à voir
Posté par Jean-Pierre Heraton . Évalué à 1.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . É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 Nelis (site web personnel) . Évalué à 1.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . É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 Yusei (Mastodon) . Évalué à 1.
[^] # Re: ce qui reste à voir
Posté par Johann Deneux . É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.
# Design et Invention
Posté par tuan kuranes (site web personnel) . Évalué à 1.
Pour ce qui ce qui est du domaine de la recherche et de l'invention, voire des evolutions, je suis totalement d'accord avec ces messieurs du kernel... Il n'est pas possible de designer, et les tests&see seuls peuvent amener de nouvelles voies !!
Mais il me semble important de garder à l'esprit que le 'design', pour ne pas dire la conceptualisation méthodologique reste la meilleure manière de gerer un projet en terrain connu... c'est à dire la plupart du temps !!!
Pour concevoir un site marchand, un logiciel de gestion ou tout autre programmation ou le cahier des charges est clairement défini, il faut 'designer' et non pas faire du test&see...
(sauf si on est parachuté par hasard sur un terrain inconnu par un commercial ;)
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 ? C'est que j'en ai pas mal à soumettre, des portions de code ou un barbare a fait un enieme memcpy qui s'appelle foobugbarsizedmove(gklint64 foo) qui faut debbuger pendant des heures et je voudrais bien militer contre !!! Si je pouvais trouver le mec qui a inventé foobar !!!
Tk
[^] # Re: Design et Invention
Posté par Yusei (Mastodon) . Évalué à 1.
Avec cette réserve, je trouve aussi que c'est une bonne idée.
[^] # le hall of shame...
Posté par Christophe --- . Évalué à 1.
Bin ca existe deja : http://www.ioccc.org/(...)
</joke>
En pratique, je pense qu'un tel site aurait vraiment une utilité. Par contre, il serait bon de rester raisonnable : classer les plus mauvais sources, mais aussi noter les ameliorations des coders incriminés.
Frapper sur les mauvais coders ne les inciteraient pas a continuer a dévellopper des logiciels open source, mais plutôt a rejoindre les projets proprietaires, où personne ne dit rien sur la qualité de leur code... (sans parler des éternelles légendes sur les coders au sources bien obscur, pour justifier et conserver leur place...)
C'est pourquoi je pense que noter les améliorations seraient alors perçue comme une forme d'encouragement, et la communauté complete aurait ainsi a y gagner, sans parler des exemples ainsi fournis aux débutants en recherche de conseils.
[^] # hors-sujet -1
Posté par Anonyme . Évalué à 1.
En es-tu bien certain ?
L'homme n'a désiré dominer qu'à partir de l'ère chrétienne, qu'à partir de 01 av J.-C.
[au passage s/"été"/"ont été"/g]
[^] # Re: hors-sujet -1
Posté par Christophe --- . Évalué à 1.
C'est honteux, mais je me suis servis de ma signature pour faire d'une pierre deux coups, et taper en même temps sur deux choses que je n'apprécie pas beaucoups...
PS: j'ai corrigé, comme tu vois, et je te remercie. C'est entièrement ma faute : je ne devrait pas travailler à des heures avancées de la nuit :) (c'est d'ailleur précisé dans le guide de l'administrateur unix: c'est vers les trois heures du matin que commencent les fatidiques rm -rf /....)
[^] # délation
Posté par Troy McClure (site web personnel) . Évalué à 1.
je ne sais pas où il est, mais par contre je peux t'indiquer où trouver l'auteur de fooplop: http://quadaemon.free.fr(...)
[^] # Re: Design et Invention
Posté par Johann Deneux . É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.
[^] # Re: Design et Invention
Posté par Yusei (Mastodon) . Évalué à 1.
Par contre il ne faut pas taper sur les gens parce qu'ils ont écris du code sale, évidemment. Et argumenter, pas dire "c'est sale, point"
(allez on va battre le record de la ml ?)
[^] # Re: Design et Invention
Posté par Axel R. (site web personnel) . Évalué à 1.
Euh, désolé, j'ai pas pu m'en empecher...
Axel - 584
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.