lasher a écrit 2738 commentaires

C'est sûr qu'un argumentaire de 300 mots sur une bannière, ça va attirer l'internaute moyen ... :)

Je pense sincèrement que L.Page, à l'origine du projet de numérisation, n'avait vraiment pas d'autre objectif que de dire « et pourquoi pas filer tous ces bouquins à tout le monde, hein ? ». Bien entendu, il est idéaliste mais pas complètement débile: il pensait pouvoir faire du fric à partir de ça aussi. Enfin voilà, cet article explique ça mieux que moi :

http://www.wired.com/magazine/2011/03/mf_larrypage/

Il y a bien quelques écrivains qui parviennent à produire des oeuvres de qualités en grand nombre pour en vivre, mais c'est très rare.

Tu veux dire, comme Alexandre Dumas (qui écrivait un nouveau truc toutes les semaines), Balzac (plus ou moins idem, avec en prime son éditeur qui l'enfermait dans une pièce jusqu'à ce qu'il lui sorte les feuillets), et toutes sortes d'autres écrivains ?

Oui, je suis d'accord, il n'y en a pas beaucoup, mais voyons voir... En règle générale, j'ai une règle du 80/15/5. 80% de merde, 15% de mecs qui font des trucs pas mal du tout, généralement inspirés par les 5% restants qui sont autant de génies. Je ne vois pas en quoi c'est un problème.

• Les logiciels sont couverts par des contrats de licence qui les lient aux utilisateurs.

Bon là c'est moi qui suis confusionné. Je croyais que « contrat » et « licence » c'était pas la même chose ?

Oups, tu as raison, d'après Wikipedia:

Applicative order (or leftmost innermost) evaluation refers to an evaluation strategy in which the arguments of a function are evaluated from left to right in a post-order traversal of reducible expressions (redexes). Unlike call-by-value, applicative order evaluation reduces terms within a function body as much as possible before the function is applied.

Donc « strict » : qui évalue l'intégralité des paramètres avant d'exécuter la fonction; « ordre applicatif » (traduction pifométrique): qui évalue de gauche à droite.

En fait je crois que j'ai confondu avec certains qui parlent de « fully strict » pour parler de « applicative order ».

Sinon, tes 2 go de rm, ils sont fait pour etre consommes. De la ram libre ne fera pas tourner ton systeme plus vite. Je prefere avoir mes 2go pleins en permanence plutot que de passer mon temps a lire depuisnun disque (potentiellement fragmente). Les ssd vont peut etre changer la donne, mais on en est pas encore la.

Dans une optique de performance, je suis tout à fait d'accord. Dans une optique de gestion et d'économie d'énergie, on veut pouvoir éteindre une partie de la RAM quand elle ne sert pas. Même sur une machine type PC (je pense aux portables par exemple).

Les structures de données (domaine où il est impossible d'être exhaustif), les threads (ou tout autre manière de supporter du multitâche), gestion du réseau,.... tu t'arrète où ? AWT fais parti de la bibliothèque standard de Java.

Oui alors euh, justement, pour les threads, il y a de très bons articles (je ne sais pas s'ils sont disponibles librement sur le net) qui expliquent que par exemple les threads ne devraient pas être implémentés dans une bibliothèque. Par exemple, Threads Cannot not be Implemented as a Library a été écrit par J.Boehm, l'un des concepteurs du modèle mémoire du prochain standard de C++. The Problem with Threads, écrit par E.A. Lee, explique bien les problèmes liés à la façon dont le parallélisme dans les langages actuel est généralement mal exprimé et donc exploité.

Je suis totalement d'accord avec cette vision des choses (et un jour, OoOooOoh oui, un jour, j'écrirai un journal sur ce thème). Tant que les threads (ou une quelconque façon de gérer le parallélisme) sera exprimé à coup de PThreads, tant que les compilateurs considéreront qu'ils optimisent pour des programmes mono-thread (et donc effectueront des transformations dangereuses), etc, alors on aura toutes les difficultés du monde à produire des programmes parallèles efficaces sans passer un temps fou à les debugger.

Dans un langage de programmation, avoir une « évaluation stricte » signifie qu'on évalue les arguments d'une fonction sous forme de recherche en profondeur et de gauche à droite dans l'arbre d'appel des fonctions. C'est-à-dire: les arguments d'une fonction sont toujours évalués de gauche à droite, récursivement jusqu'à avoir évalué tous les arguments de toutes les fonctions nécessaires à l'appel de la fonction initiale.

Ce dont tu parles ressemble beaucoup à de l'inférence de type (du genre de ce qu'on trouve dans les langages fonctionnels).

Oui ben à ce propos, j'ai jamais vu dans la doc Intel où on pouvait avoir des pages d'1Gio. 2MiB iu 4MiB, oui, c'est dedans. Mais sinon je vois pas. L'autre problème est aussi que la taille de la TLB pour les pages de 4Kio est de 128 entrées (de mémoire), alors que pour les grandes pages, il n'y a que 4 entrées (toujours de mémoire). C'est aussi ce qui explique selon moi pourquoi on ne doit pas (pour le moment) avoir des grosses pages par défaut.

Ce que l'on peut surtout retenir de la propriétarisation de Nessus c'est qu'un logiciel peut être très populaire sans pour autant attirer de contributions. http://www.useit.com/alertbox/participation_inequality.html le dit assez bien sans pour autant apporter de solution miracle.

C'est vrai. Je pense cependant que l'absence de contribution n'était pas tellement le problème. Le vrai problème (dans le cas de Nessus) était le nombre de boites qui utilisaient le soft, corrigeaient des bugs quand elles les trouvaient, mais ne remontaient pas les patchs. Je pense que si les gens de Nessus avaient vu que personne ne contribuait activement (donc les « 90% de lurkers » du lien que tu donnes, ou même 99% dans le cas de Nessus), ils n'auraient pas trop gueulé. C'est vraiment la façon dont des entités privées ont récupéré le boulot sans jamais rien reverser qui a énervé les dév. originaux de Nessus.

A l'origine était Nessus, scanner de vulnérabilités. En 2005, l'auteur décida de quitter les chemins du libre et de continuer le développement sous forme d'un logiciel privateur. La communauté créa un fork à partir de la dernière version libre. Initialement appelé GNessUs, le projet fut renommé OpenVAS.

Nessus était libre à la base, et est devenu proprio, certes. Il y a une raison a ça : personne ne contribuait. Plus exactement, les boites de consulting faisaient exactement ce que la licence libre autorisait (i.e. repackageaient le soft, et le faisaient passer pour un super soft maison à la pointe du progrès). Certaines corrigeaient même Nessus. Elles "oubliaient" juste de remonter les patchs. Bizarrement, l'auteur original en a juste eu marre, et a décidé de rendre la version 3 de Nessus propriétaire. Et la, ô miracle, certains se réveillent, et décident enfin de contribuer (d'ou OpenVAS).

Il est maintenant la pierre angulaire de l'activité de plusieurs sociétés, sur trois continents. Ces sociétés développent activement le logiciel et ont construit tout un modèle économique autour de lui.

Combien y a-t-il de mainteneurs ? Sont-il tous de la meme boite ? Parce que je vois bien le scénario Nessus se répéter pour OpenVAS dans quelques années.

Mais justement, tout le monde fait pareil, tout le monde est au courant, et tout le monde sait que tout le monde veut faire passer ses idées, etc., et tout le monde se connaît dans le milieu. Je ne vois pas en quoi MS détonne plus que les autres ici.

Je connais merci. Et tu sais quoi ? Cette politique, même si elle reste sans doute vraie de la part de MS à bien des niveaux, est bien plus difficile à appliquer dans le cas d'un comité de normalisation — justement parce que euh, cette fois, ils poussent leurs fonctionnalités pour les inclure dans la norme. Et bien entendu, si ça passe, ça veut aussi dire qu'ils auront déjà l'implémentation toute prête, là où les autres devront peut-être consacrer du temps de dév (et donc de l'argent) pour s'adapter. Ça arrive aussi pour le standard OpenMP, où Intel a beaucoup poussé pour inclure la notion de liste de tâches (task list) dans le standard, pour gérer la récursion et des trucs type listes chaînées ou arbres. Au final l'idée a été retenue, mais avec un syntaxe et une sémantique différentes de ce qu'Intel avait déjà implémenté dans ses compilateurs ...

Bon là tu dis un peu de la merde. Et je te renvoie aux tests effectués sur FF à une époque, et qui montraient que FF3 (si je me souviens bien) était plus rapide en passant par la version Windows+Wine que la version native linux, tout simplement parce que sous Windows ils utilisaient l'optim par profilage. Une optimisation efficace se fait presque toujours aux dépends de la portabilité...

Alors euh, même si je suis d'accord sur le fait qu'il faut toujours étiqueter ses graphes, ton ton condescendant (certificat d'études, tout ça ...) me fait un peu vomir. Le fait qu'un auteur oublie de le faire (mais précise quand même les unités dans son article, par ailleurs) n'en fait pas quelqu'un de pas crédible.

Tu as juste décidé que tu n'étais pas d'accord parce que pour toi, MS c'est caca.

c) MS a de gros intérêts financiers à voir des développeurs passer à d'autres langages, et freine des 4 fers toute avancée du C, en proposant un compilo C incomplet face à ce qui se fait sur le marché et en noyautant les organismes de standardisation.

N'importe quoi. Il faut arrêter la paranoïa un peu. C'est comme si tu disais que l'une des personnes qui a mis au point le nouveau modèle mémoire de Java avait désormais tout intérêt à voir celui de la future norme de C++ s'écrouler (et pour info, il y a bien une personne qui a aidé à spécifier le JMM, et la même qui aide à le faire en ce moment aussi pour C++ ...).
C'est comme si tu disais que puisque désormais, Leslie Lamport bosse pour MS Research, sa recherche ne vaut plus rien.

Bref. MS a un intérêt commercial à avoir un langage C qui lui convient et qui convient aux gens qui programment pour son système. Ni plus, ni moins. Et bien entendu, ils vont essayer de pousser certaines fonctionnalités dans un sens qui les arrange. Exactement comme dans tous les comités de normalisation.

<div class="rms">Mauvais boulot, changer boulot.</div>

-------->[ ]

L'anglais n'est pas si précis que ça. Et le français propose lui aussi des nuances extrêmement subtiles de son côté. Il s'agit simplement de nuances sur des sujets différents.

Par exemple, le mot « fuck » doit systématiquement être remis dans son contexte pour pouvoir correctement le traduire en français ... :)

Mmmh, s'il s'agissait de vraiment prendre uniquement un langage simple, il faudrait préférer l'espagnol à l'anglais, car ce dernier comporte tellement d'exceptions que c'en est risible. Ah, et aussi, un dico anglais est généralement deux fois plus épais qu'un dico français, pour une raison toute bête : Guillaume le conquérant est passé par l'Angleterre en 1066 (si ma mémoire ne me trompe pas). Du coup, il a imposé le « français » (je pense qu'il s'agit plutôt d'une forme de bas Latin à ce moment-là) à la cour.

Bref, il existe des nuances sémantiques dans la langue anglaise que la langue française n'a pas, et inversement.

Je suis d’accord pour dire que la vectorisation est facilement réalisable automatiquement pour les cas simples (c’est bien pour ça que je me suis contenté d’écrire 1:N dans le premier cas, comme le Fortran le permet, au lieu d’une version C qui masquerait ça). Mais pour moi ça nécessite toujours de penser les algos. dans ce sens, il suffit de quelques variables temporaires dans la boucle, qu’un élément j du vecteur attende le résultat sur l’élément i et la boucle n’est plus vectorisable de façon triviale, voir pas du tout dans le cas d’un arbre.

Il ne faut pas confondre trois choses :

1. L'algorithme général qui permet de régler ton problème, et
2. la façon dont tu implémentes la solution (et les structures de données afférentes)., et enfin
3. les (micro-)optimisations que tu peux faire sur un code.

Les deux premiers points sont les deux plus importants, car ils t'apportent une solution correcte. Le troisième point, si les deux premiers ont été correctement effectués (meilleur algo possible pour le problème à résoudre, meilleur choix de structure de données pour réaliser l'implémentation de l'algo, etc.), alors on peut enfin se pencher sur la (micro-)optimisation du code.

Et oui, si tu veux juste traverser un arbre (pour faire un parcours en profondeur par exemple), mais que tu n'as pas de gros calcul à effectuer sur les nœuds, alors la vectorisation est inutile (ou infaisable). Mais tu parles déjà d'un type de programmation bien plus avancé que ce que la plupart des gens connaissent. Pour la plupart des physiciens ou numériciens que j'ai pu croiser, si le compilateur leur dit « j'ai vectorisé tes boucles », ils sont tout contents, mais sinon, de toute manière, ils ont ce gros machin MPI à écrire, et ça leur bouffe déjà la plupart de leur temps de cerveau disponible. :)

Ce qu'il nous faut en fait, c'est le même genre de bibliothèques de bases que ce qui est proposé en Java par exemple (dans util.concurrent si je me souviens bien — en tout cas un truc dans le genre) ou en C++ avec Boost (même si pour le moment c'est un peu léger) : des machins qui sont « parallel-proof » (dans une certaine limite). Et il nous faut d'autres gens qui programment d'autres structures de données qui permettent des accès concurrents efficaces (pas de gros verrou en entrée de la structure de donnée par ex). Sauf que la programmation efficace de ce genre de bibliothèque n'est pas à la portée du premier venu. Par exemple, une implémentation concurrente et efficace d'une liste chaînée passe par l'utilisation d'opérations de type compare-and-swap, pour « verrouiller » atomiquement (et efficacement) un maillon de la chaîne que tu traverses. Les algos pour le faire sont loin d'être triviaux. Par exemple, je t'encourage à aller regarder du côté des implémentations lock-free des Skip-list : le papier original explique très bien comment faire, mais malgré tout c'est pas évident à réaliser sans bug.

Bref, il nous faut des gens qui nous fournissent des implémentations génériques et efficaces (en C, C++, etc.) de structures de données qui gèrent la concurrence. Sur une machine « normale » (entre 2 et 8 cœurs ou threads), ces algos sont suffisants pour garantir un passage à l'échelle. Sur une grosse machine parallèle, là oui, il va falloir travailler un peu plus. Mais c'est ce qui fait que je vais avoir du boulot pour les dix prochaines années au moins ... :)

Argl, et je vois une énôôÔôÔôrme faute dans le message précédent : C est bien typé, mais faiblement (donc pas fortement ! :-))

Bon, j'ai fait une thèse, et s'il est vrai qu'une portion non-négligeable venait comme moi d'école d'ingénieur, ce n'était clairement pas la majorité dans mon labo. Et c'est très bien comme ça : ça permet de mélanger un peu les historiques.

Enfin dans tous les cas, tu as tort, la majorité des doctorants ne vient clairement pas de grandes écoles. Et comme ni toi, ni moi n'avons de chiffres concrets, je vais me cacher derrière un argument d'autorité et te dire que je suis docteur, moi monsieur. ;-)

Ah oui mais là par exemple ça pose problème : la plupart des codes (même industriels hein) que j'ai vu tourner étaient écrits au mieux en Fortran 90. Je ne doute pas que plein de gens se soient mis au goût du jour, mais c'est comme pour C99 : l'adoption des nouvelles normes est extrêmement lent.

Ensuite j'ai regardé ta page, et forall en F95 et supérieur est différent du foreach en Perl, Java, etc., puisqu'il ne concerne finalement que des objets de type tableau, là où dans les autres langages ça marche pour n'importe quel type de collection, et surtout, sans besoin d'utiliser de variable d'indexation.

Sans compter le fait que LISP par exemple a été extrêmement précieux dans la création d'AutoCAD par exemple...