Moby-Dik a écrit 2937 commentaires

ça m'étonne pas qu'ils n'en soient pas capable, c'est la misère à compiler du C

Oui, mais en fait on ne te demande pas trop si tu penses qu'ils en sont capables, mais plutôt s'ils le sont réellement. Là c'est un rideau de fumée que tu nous fais.

j'ai jammais dit qu'il fallait tout récursiviser, il va falloir arrêter la mauvaise foi

Tu ne l'as pas dit, par contre c'est à peu près ce qu'imposent les langages dont tu te fais l'avocat (caml...).

si t'as des alphaservers de production (comme on en voit chez des grosses boites) blindés en mémoire, tu t'en fous un peu qu'il bouffe de la RAM et du CPU.

Mais bien sûuuuuuur :)) Si on te donne des alphaservers, c'est certainement parce qu'il y a un paquet de charge à soutenir, donc c'est pas avec un bouzin mal optimisé que tu t'en tireras.

Sinon, hormis les performances en calcul brut, je ne suis pas sûr que les alphas aujourd'hui soient beaucoup plus puissantes qu'un gros Xeon 2 GHz avec la mémoire en rapport. A voir ;)

Je ne pense pas, je n'utilise jamais ce genre de trucs.

F-CPU prévoit un truc pour les langages fonctionnels

"Un truc", la belle jambe. L'ensemble du jeu d'instruction est quand même tout à fait classique, et beaucoup plus proche de ce qu'on peut exprimer en C que du car/cdr :))

prends smalltalk, la grammaire tient sur un ticket de métro ou encore mieux prends Forth, elle tient sur le haut du ticket.

Si c'est vraiment un critère pour toi, tu n'as qu'à prendre Intercal, ou l'assembleur 6502.

le compilateur va virer derrière mon dos un paquet des appels de fonctions que j'ai écris (et les tranformer en saut direct) et bien qu'il le fasse

M'étonnerait que les compilateurs C n'en soient pas capables, tu sais.

en plus ça vire les problèmes de récursivité sur certaines fonctions

Il y a peu d'algorithmes récursifs de façon inhérente. Injecter de la récursivité partout, c'est une contrainte foireuse des langages type Lisp. Ca rend le code difficilement lisible (quand un algorithme n'est par essence pas récursif, l'implémentation récursive est souvent tordue) et source de beaucoup d'erreurs potentielles (vérifier la réentrance, etc.).

On ne parlait pas de performance mais de fiabilité

Pourtant le post précédent disait : "ils ne sont pas viables pour un projet aussi critique niveau perf qu'un serveur Web". Donc on parlait bien de performance.

C'est clair qu'un algo codé en C est généralement plus rapide mais cela ne sert à rien si le l'application est sujete à un DoS

Si tu te places dans une perspective académique, certes. Si tu es dans la vraie vie, que tu mets en place en serveur Web, et que tu as le choix entre :

- un machin en C/C++ rapide et léger mais qui a une espérance de plantage de deux ou trois heures par an à cause de bugs divers.

- un machin en SuperLangageHautNiveauApprouvéParMonProf blindé algorithmiquement, mais qui nécessite trois fois plus de mémoire et de CPU pour faire la même chose que le précédent, et qui va planter la machine en cas de pic de connexions car il va bouffer tout le swap.

... eh bien, si tu as ce choix, tu vas probablement décider de prendre le premier (ou alors c'est que tu décides mal). Une fois face à ce genre de problèmes, tu te fous de savoir si écrit en Javacaml, le bouzin serait potentiellement plus fiable d'après une hypothétique théorie du logiciel.

M'est avis qu'il doit pas être bcp utilisé non plus :)))

et en plus c'est orienté objet

Ca fait une belle jambe, pour un serveur Web ;)

nos grands chercheurs de l'INRIA se cassent le cul a développer des langages magnifiques (bon ok le terme est un peu exagéré)

C'est surtout pour "grands chercheurs" que le terme est exagéré, à mon avis :)

et pi un bon algo et des bonnes structures avec un bon niveau d'abstraction

C'est possible en C, et encore plus en C++.

et pis le bytecode Caml est (a peu près) compatible Java

Ben, c'est cool, les sources C sont compatibles avec les compilateurs C. Que demande le peuple ?

Ca dépend peut-être des implémentations de la gestion d'exceptions C++, mais il me semble qu'on peut récupérer les exceptions hard (traps...) avec un catch(...). En tout cas ç'eut marché un jour quand je m'en servis pour la division par zéro (me rappelle plus sur quelle architecture), ou alors ma mémoire me joue de gros tours.

J'ai de plus le sentiment que c'est un sujet qui te préoccupe grandement.

Disons qu'en tant qu'informaticien, ça m'arrive d'écrire des programmes. Toi aussi, j'imagine.

Ce que je ne tolère pas dans tes propos, outre le fait qu'ils sont résolument engagés

Pourquoi "outre" ? Avoir des propos engagés est répréhensible en soi ?

Bref, tu n'accordes pas la moindre attention à ce que les autres peuvent penser ou dire

Hum, vu le résultat de ce fil, je pense au contraire en avoir accordé un peu trop. J'aurais peut-être mieux fait de laisser les contre-vérités insouciantes et dangereuses s'accumuler, au moins je ne me serais pas fait chier.

C'est pas avec des propos injurieux que tu vas t'attirer ma sympathie,

C'est pas le but non plus.

Le www est si vaste, j'aurais vite fait de me trouver un site de news animé par des gens un peu plus tolérant que toi

Je n'anime pas Linuxfr ;)

(-1)

Faudrait p'têt voir à suivre les liens proposés avec la news

C'est bien que tu le dises. Extrait du premier lien :

"SAN FRANCISCO (Reuters) - Les éditeurs de logiciels informatiques doivent-ils être tenus pour responsables des défauts de leurs produits, comme le sont les constructeurs de voitures par exemple ?

Derrière cette question dont la réponse peut amener plusieurs milliards de dollars de dommages et intérêts [...]"

Responsabilité, dommages et intérêts, c'est pas du vocable juridique, peut-être ? Plus loin, des propos d'avocats sont rapportés, c'est pour parler de l'efficacité du noyau Linux, sûrement.

Mais encore : "l'Académie nationale des sciences [...] a pressé le législateur de réfléchir à une réglementation". Et puis aussi : "Aux Pays-Bas, un tribunal a jugé en septembre dernier la société Exact Holding coupable d'avoir vendu un logiciel bogué".

Y a pas à dire, ça ne parle vraiment pas d'enjeux juridiques et légaux. Parole d'informaticien !

T'es juriste ? Excuses-moi de n'être qu'un simple informatitien

Non, je suis informaticien, mais toi tu es un boulet.

Je crois bien que tu t'égares un peu, car d'une tu n'es pas au tribunal

Je crois que c'est toi qui n'a rien compris, car la brève parle de responsabilité juridique. Après si tu préfère intervenir hors sujet en laissant entendre que tu réponds quand même à la brève, ben....

Pour le reste... pouf, pouf ;))
Allez, -1.

En résumé, et pour faire bref, je voulais simplement signifier qu'il me paraissait inconcevable d'exiger la même part de responsabilité d'un logiciel propriétaire (et souvent cher) et d'un LL.

Et moi ce que j'essaie de te faire comprendre, c'est qu'un juge se fout de savoir ce qui est inconcevable pour toi ou pour l'informaticien averti. Toi y en a suivre l'actualité juridique, des fois ?

Mais au départ, même inconsciemment, tu conclus, peut-être par habitude que produit moins cher=moins de qualité (et à ce moment là, ça ne t'étonne pas)

Ca apporte quoi ce genre de remarques ? Tu crois qu'un développeur de LL va pouvoir se dédouaner de toute responsabilité devant un tribunal avec ce genre d'argument ? T'es pas un peu inconscient (ou con tout court) ?

Si je suis énervé, c'est parce que je vois des gentils couillons comme toi qui pensent que la justice sera infiniment plus compréhensive à l'égard des développeurs bénévoles de leurs produits préférés. Ca t'arrive de redescendre sur terre et de sortir du bel univers imaginaire où tout le monde il est beau il est gentil ? Tu veux pas faire preuve d'un peu de clairvoyance, une fois, rien qu'histoire de ne pas balancer des tonnes de mensonges dangereux ?

C'est fatigant, de discuter avec des pignolos pareils.... :(

Mon Dieu les angéliques :((

Par contre, dans le cas du LL, les sources sont ouvertes, et donc, l'utilisateur, qu'il télécharge ou achète de tels logiciels a la possibilité d'en comprendre le fonctionnement, et éventuellement d'empêcher certaines exceptions en changeant ces-dites sources et recompilant les programmes dans le but de l'utiliser.

Je te laisse essayer de vendre une voiture (ou autre machin) "dont les sources sont ouvertes" et d'arguer que, si un mec se tue à cause d'un défaut quelconque, il n'avait qu'à faire une code review avant. Faut arrêter de rêver, là. Y a des GrosPleinDeFric SA et autres SuperLobby Corp. qui n'hésiteront pas une seconde à balancer une horde d'avocats aux trousses de Redhat s'ils ont un préjudice de millions de brouzoufs suite à leur malcompréhension de tel ou tel bidule dans la distribution. On peut même imaginer qu'ils s'amusent à essayer de ruiner un particulier si celui-ci est une figure importante (remember Altern, Estelle et Valentin ?).

Enfin, dans le cas des LL gratuits, ils sont pour la plupart développés par des volontaires, sur leur temps de libre, et je ne vois pas comment on pourrait les rendre responsables de quoi que ce soit.

De même, dans le cas des forums gratuits du site Web d'une association à but non lucratif de défense de consommateurs, on ne voit pas comment on pourrait rendre responsables les webmestres d'un message diffamatoire posté sur le forum, et leur demander 80 000 Euro de dommages et intérêts. Dommage, c'est arrivé quand même.

De plus, d'après la connaissance que j'ai du sujet (qui est loin d'être complète, je vous l'accorde), il me semble que les LL sont plus précis dans ce qui fonctionne ou non (cf. fichiers INSTALL, TODO, README joints dans 99% des cas)

Faudrait arrêter de raisonner de travers. Le problème n'est pas de savoir si les logiciels peuvent éviter un maximum de désagréments, mais s'ils le doivent sous peine de dommages et intérêts. Tain, c'est pas difficile à comprendre, non ? Quand je vois 90% des messages ci-dessus qui se contentent de barrir "de tte façon Linux plante pas, bien fait pour kro$oft", j'ai l'impression d'un troupeau de neuneux qui batifolent sur le chemin de l'abattoir :(((((((((((

Et autre chose, c pas parceque la majorité des gens utilises IE que c le meilleur navigateur,

Faut que je t'explique un truc mon petit : je répondais à une affirmation de l'article. Dans la vie, quand on intervient dans une discussion, il est bon de se renseigner sur le contexte. Aussi, on évite d'attribuer aux gens des choses qu'ils n'ont pas dites.

Maintenant, c'est bon, tu peux retourner sur irc ;)

(allez, -1, parce que j'ai tout fait pour qu'il s'énerve, là)

[...] et Opera a fini par s'imposer sous Linux et sur les machines peu puissantes

Ha ha ha hou hou ! Trop drôle :)) Opera...

J'ai accès aux stats d'un site tous publics (pas un truc d'informaticiens quoi, et quelques milliers de visites par jour), et voilà ce que je constate dans les user-agents cumulés par Webalizer :

- "Mozilla/5.0" (inclut donc Mozilla, Netscape 6/7, Konqueror...) : plus de 5 %

- Opera (toutes versions) : moins de 1 %

Un sacré putain de navigateur qui s'impose à fond les manettes, Opera ;)
Allez, hop, poubelle le journaliste.

Oui, entre autres. Plus exactement, il y a deux grandes catégories d'écueils : quantitatifs et qualitatifs.

• Qualitatifs : Il y a plusieurs choix à faire. - Le mode de représentation des variables du problème. Il s'agit en général d'un compromis entre facilité d'obtention et de traduction vis-à-vis du problème réel d'une part, et possibilité d'utiliser des fonctions performantes d'autre part (voir ci-dessous). - La fonction de sélection de la population d'une génération à l'autre (fonction de fitness). Le plus souvent il s'agit d'un choix empirique, le problème ne permettant pas de formuler une fonction de manière exacte. - Les fonctions de mutation et de croisement permettant de créer aléatoirement de nouveaux individus dans chaque génération. A priori, la façon dont ces nouveaux individus sont créés à partir des anciens doit n'être pas totalement arbitraire, mais respecter la sémantique du problème (par exemple si je mute à partir d'un individu proche d'une solution optimale, il serait de bon ton que l'individu obtenu par mutation ait des chances de lui aussi être proche d'une solution optimale ;-)).
• Quantitatifs : - L'espace décrivible par les variables du problème est en général immense (probablement infini, et peu adapté à une quantification trop grossière). Il faut néanmoins arriver à des résultats avec une population restreinte (quelques dizaines de milliers d'individus par génération par exemple). - La convergence n'est pas immédiate. En multipliant le nombre d'individus par le nombre de générations, ça fait un sacré nombre de tests. - Corollaire 1 : les algos g ne sont intéressants que lorsqu'il est hors de question de trouver un cheminement déterministe raisonnable pour arriver à la solution. - Corollaire 2 : même dans ce cadre, les fonctions de sélection, de croisement et de mutation ont intérêt à être rapides (d'où le problème d'une bonne représentation des données, ce qui est loin d'être évident sachant que le croisement "de base" est le remplacement d'un bout de chaîne (de bits ou d'octets) par un autre bout de chaîne et que cela doit pouvoir conserver au moins empiriquement certaines propriétés de l'individu).

Voilà voilà. Tout ceci est assez livresque, mais les propriétés citées plus haut sont logiques en soi - et confirmées par l'expérience de ceux qui y ont mis les pattes. NB : dommage que ça s'appelle "algos génétiques", ça amène à la confusion des tas de gens. Au moins on peut dire "réseaux neuro-mimétiques", ce qui souligne qu'il y a une analogie métaphorique au départ, mais pas de lien scientifique fort. Algos généticomorphes ?

mais non c'est pas pipeau ! (essaie de taper 'genetic algorithm' dans google par exemple) Ca fonctionne comme dans la nature : si tu veux obtenir un super cheval de course, tu va croiser des chevaux "champions" pendant plusieurs générations, le patrimoine génétique des individus s'améliorant de génération en génération. Ce qui est pipeau en soi ce n'est pas l'existences des algos gé, mais plutôt l'idée que certains se font de leur efficacité. Il n'y a aucune raison qu'un algo G soit forcément capable de trouver une solution à un problème ; les algo G, c'est fondamentalement du random amélioré. Aucun théorème ou même axiome ne permet de prédire la réussite d'un algo g de façon généralisée. Et question performances, c'est en général loin d'être génial (explosion combinatoire). Je comprends assez le scepticisme de la personne précédente, car déjà traduire les possibilités de mouvement (analogiques, continues) d'un robot en critères ou décisions discrets (ce qui est a priori nécessaire pour utiliser un algo g) est loin d'être évident.... Du reste, le mécanisme de "test and trial" inhérent à l'AG n'est certainement pas appliqué aux mouvements du robot lui-même, sinon 1) ça prendrait un temps fou 2) le robot serait complètement bousillé (à force de tomber :-)) avant même que l'algo puisse tomber sur une solution raisonnable. Donc il y a autre chose que l'algo gé. Mais c'est vrai que l'algo g en soi est quelque chose d'assez fascinant à première vue, donc un très bon argument marketing. Amen :))

si on est vicieux une GiPi, mais c un peu salaud quand même Pourquoi, c'est pourri la Gipi ? J'ai cru comprendre qu'une coopérative commercialle s'est créée pour la distribuer alors même qu'il n'y a rien de prêt. Mouais.... Un peu étrange cette façon de mettre la charrue avant les boeufs (ce n'est pas une insulte pour les geeks) ;)) Quelqu'un peut m'expliquer le bidule ?

Sur le point précis de Linux (le noyau, donc pas GNU/) et la GPL, le dernier kernel traffic est assez intéressant. On y lit les problèmes de RTAI (Linux avec une sous-couche temps réel) à cause de problèmes de brevets et de soi-disant conflits avec la GPL. L'intervention de Linus montre bien qu'il est loin de se foutre des problèmes associés au code non-GPL : «Does the RT part have to be GPL? Yes. Big whoopte-do. So does kernel modules in general, if they are clearly derived works of Linux (which, in something like this, is pretty obviously the case). So you split your problem into the RT device driver and the user. And of story. Stop this stupid FUD. The thing that disgusts me is that this "patent" thing is used as a complete red herring, and the real issue is that some people don't like the fact that the kernel is under the GPL. Tough cookies. Stop making excuses. I'm personally really happy with having another reason why people should make all their kernel modules GPL'd. I see way too many problems with things like the nVidia kernel modules etc, and I realize that the GPL scares away some people, and I don't care. Some people (you and Karim) seem to think that the GPL requirement si going to hurt Linux in the embedded space. Fair enough. That's what all the BSD people claimed was the case about Linux in server space, Linux on the desktop, or Linux anywhere. Personally, I'll just bet on open source myself. Even in the embedded space. And anybody who bets against me, I just don't care about, because it has zero impact on me.» Le Kernel Traffic : http://kt.zork.net/kernel-traffic/latest.html

Ma supposition faute d'avoir l'avis officiel du projet GNU est que ça ne les intéresse pas car ils ne sont pas assez connus. AMHA il s'agit plus de gagner de la notoriété que de réparer un préjudice...

Ceci dit il n'aurait pas tort de répondre que le préjudice est proportionnel à la notoriété, et qu'il cherche à réparer le plus gros ;)

D'abord les djeun'z ne s'envoient pas des troyens mais des chevaux de Troie (trojan en anglais).

C'est un peu réducteur. Pourquoi certains jeunes ne s'enverraient-ils pas des Troyens ?

C'est un troll ?

Non, c'est un cheval.

Non, le problème c'est que pour l'instant le trafic est inexistant ;)

Rien de très original ;)

Ce qui serait surtout marrant, c'est de savoir s'il y a des ISPs qui font tourner des machines de production sous Winchose ! :)

Chais pas pourquoi, mais j'ai toujours préféré les moustiques aux cousins. Les cousins, ça pique pas, mais c'est gros, ça vole partout comme des cons, ça serait même capable de fumer des pétards avec les copains. Enfin bref, ça doit être mon côté maso.