khivapia a écrit 2562 commentaires

Sans oublier que ça facilite l'intégration des documents d'un type dans un autre : une partie d'un tableau dans une présentation, etc.

Circuits "alternatifs" (en voix d'exploration): mécénat,

Il ne faudrait pas oublier que historiquement, le mécénat a toujours été extrèmement important, jusqu'au 19ième siècle. La production par des boîtes s'est essentiellement répandue au 20ième, jusqu'alors l'art vivait de mécénat quasi-exclusivement.

Tous les grands peintres, par exemple de la Renaissance, étaient financés par des mécènes (jusqu'aux écoles de peinture grâce à la réputation d'un maître particulièrement apprécié) où à la sortie les jeunes peintres cherchaient des mécènes. En musique également : Mozart http://fr.wikipedia.org/wiki/Wolfgang_Amadeus_Mozart pour ne citer que lui était employé durant une grande partie de sa vie, et après avoir acquis son "indépendance" il ne vivait que de commandes (donc de mécènes).

ne serait-ce pas un algorithme du même style ? À vue de nez ça ressemble un peu à ce que doit faire LaTeX quand il choisit correctement les espaces entre les mots pour obtenir le fameux "gris typographique", et il le fait en une seule passe (!).

sinon peut-être regarder du côté de l'algorithme de Viterbi, mais celui-ci n'est pas efficace pour de grandes quantités de données...

Il me semble que c'est surtout dû au fait que les développeurs ne prennent pas la peine de tagguer les bugs "lenny-ignore" ou "stable-ignore". Il serait pour le moins étonnant que le nombre de bugs de lenny ne cesse de croître alors que ça n'a jamais été le cas sur le graphique pour les précédentes stables...

Si le but est de te laver publiquement des soupçons infondés et mensongers, l'enquête devrait aboutira certainement.

Ça ressemble un peu à prouver qu'on est innocent... Ah là là la calomnie ne serait pas ce qu'elle est si tout le monde attendait des preuves pour croire.

Cela dit le problème de la confiance est une vraie difficulté pour Freenet. La confiance qu'on a en des gens introuvables s'obtient en étant crédible. C'est une vraie éducation : ne pas croire tout bonnement tout ce qu'on raconte, vérifier les faits énoncés, recouper les analyses, etc.

C'est d'ailleurs selon moi la vraie solution à tout ce genre de problèmes : l'éducation et l'instruction, apprendre à tous à ne pas croire bêtement tout ce qui est dit ici ou là. Ça détruit la calomnie de fait, et à mon avis tout le monde est plus heureux car plus libre (et non plus le jouet de tel ou tel bonimenteur). C'est d'ailleurs la moindre des choses quand on ne veut pas se faire entuber par les offres commerciales en tout genre, les propositions de crédit, la publicité etc.

Ici il ne s'agit pas d'empêcher la justice, Freenet et consorts sont là pour pallier les déficiences de la justice (pour ne pas parler de son absence en Chine, en ce qui concerne la liberté d'expression).

Dans la même veine, que penses-tu de Wikileaks ? Les sources sont protégées tout autant que sur les réseaux anonymes, et comme disaient certains journalistes récemment, Wikileaks a révélé plus de scoops en 10 mois que le New York Times en 100 ans" (ordre de grandeur). Et quoiqu'en disent certaines banques islandaises ou autres malversants dénoncés, l'existence de wikileaks est une bonne chose. Toutefois, ses administrateurs sont soumis à pression. Freenet & co désirent juste devenir le wikileaks des pays sans liberté d'expression, rien de plus.

Alors que Freenet a l'air capable de trouver d'autres freenautes "à l'aveuglette" sans demander une liste (si quelqu'un peut confirmer) à un ou des serveurs centraux.

En fait Freenet a deux modes :
* l'opennet où le nœud se connecte à des nœuds inconnus. L'inconvénient est que si un gouvernement a à sa disposition un grand nombre de nœuds, il peut faire une certaine analyse de trafic...
* le darknet où le nœud se connecte à des nœuds amis après échange de référence.

Bien entendu on peut mixer les deux.

Un darknet entre deux nœuds étant un peu limité (quoiqu'un groupe d'activiste peut facilement se constituer un réseau privé intéressant), la connexion à l'opennet se fait des façons suivantes :
1) récupération d'une liste de "seed-node", ou nœud racine, qui acceptent de relayer des demandes de connexion au reste du réseau en provenance de n'importe qui. Cette liste se trouve avec l'installateur freenet;
2) relai des demandes de connexion à l'opennet via ses nœuds darknet. Si le nœud A est connecté en darknet au nœud B qui lui est relié à l'opennet, que la liste des "seed-nodes" est bloquée pour A, ses requêtes de connexion seront relayées par B, le bootstrap sera juste un peu plus lent.

La connexion est donc quasiment toujours possible une fois qu'une masse critique de nœuds derrière le grand firewall est connectée à l'opennet.

Des aiguilles plutôt : voir http://fr.wikipedia.org/wiki/If_%28botanique%29

C'est un conifère, pourtant il n'est pas résineux (comme les sapins). C'est l'arbre le plus toxique connu : tout est toxique par ingestion chez lui, des feuilles aux fruits en passant par le bois, à l'exception de la pulpe du fruit (mais ne croquez pas la graine).

Euh je ne comprends pas la différence. Dans le cas d'un chauffage, par exemple, avec 1kW (ordre de grandeur pour fixer les idées) électrique on peut faire passer 3 kW de chaleur de l'extérieur vers l'intérieur. Pourquoi avec une clim on ne pourrait pas, avec toujours 1kW électrique, faire passer 3kW de chaleur de l'intérieur vers l'extérieur ??
Évacuer la chaleur est la puissance utile de la clim et c'est certainement celle qui est mise en avant par les constructeurs.

Ici on parle vraiment d'un problème d'implémentation, l'algorithme utilisé importe finalement assez peu, ce qui compte c'est vraiment le soin apporté à l'implémentation (et la gestion du cache en particulier vu que les entrées-sorties sont primordiales).

Le fait de battre des records pour comparer des implémentations et des algorithmes est assez classique en info, notamment dans le cas des algorithmes cryptologiques (cryptographie et cryptanalyse).

En crypto en effet, pour évaluer la sécurité des algorithmes de factorisation d'entiers par exemple (pour casser des clefs RSA) il est nécessaire de savoir leur potentiel réel, pas leur potentiel "théorique" au sens "complexité" : un algorithme peut avoir une complexité largement inférieure à un autre, s'il fait beaucoup d'entrées-sorties, se distribue mal et que la formule de complexité cache des constantes monstrueuses, il n'est pas important pour la sécurité : il ne serait performant que pour des tailles de clefs largement inutilisées. Ici c'est un peu la même chose que Fabrice Bellard a cherché à comparer.

Disons que pour démontrer que l'implémentation réalisée était plus efficace, il fallait qu'il batte le record, ensuite peu importe de combien. C'est souvent la façon de procéder en recherche.
De toutes façons il n'aurait pas servi à grand-chose qu'il le batte de beaucoup plus : les chercheurs détenant le précédent record pourront de toutes façons largement le dépasser en faisant simplement tourner leur calculateur deux jours de plus. Ce qui est intéressant est de battre le record petit à petit (à moins d'une grosse découverte qui rende tout le calcul extrèmement rapide de toutes façons), afin de pouvoir comparer plus facilement les diverses données (temps, mémoire, IO) des implémentations.

Tu peux essayer sous dosbox, c'est déjà impressionnant sous un vieux Pentium-M centrino 1.6 GHz. Idem avec windows 98 dans un qemu, sur la même machine (avec kqemu ou non), c'est très très très rapide (voire même plus). Je n'ose imaginer ce que ça donne sur un PC d'aujourd'hui, même à travers une couche d'émulation.

Non, les gibis vivent sur leur planète, qui est à droite du ciel, est plate, et penche soit d'un côté soit de l'autre (celle des Shadoks est à gauche du ciel et n'a pas de forme spéciale, ou plutôt elle change de forme) et constituent une espèce intelligente et agréable.

Sisi ça l'est. Cf http://www.wikimedia.fr/d%C3%A9duction-fiscale
C'est même écrit sur la page de don sur la wikipedia française http://wikimediafoundation.org/wiki/Global_Support/fr?utm_me(...)

Bon on est pas vendredi, mais quand même c'est trop tentant :)

Faut arrêter cette manie de facture papier, c'est pas du tout écologique!
C'est sûr que comparé à (quelques Mo sur) plusieurs disques, du papier c'est vachement moins écologique (ironie inside) ! Faut pas oublier que le disque ça se recycle beaucoup moins bien que du papier (séparation des différents matériaux difficile, composants électroniques dangereux, usinage du disque extrêmement coûteux etc.). Du papier usagé, ça ne pollue pas, un disque si. Il faut raisonner en coût global.

Et je ne parle même pas de l'infrastructure derrière pour envoyer la facture électronique et la gérer...


Et cet endroit, c'est aussi fiable qu'un disque dur : dégât des eaux, incendie.
et le papier c'est aussi soumis aux aléa tels que crash disque, surtension de courant qui bousille le PC et les données, etc. etc. aussi tant qu'on y est ?

tu donnes un exemple de PDF où on ne peut pas copier le texte
C'est plus grave que ça : ça dénote une tendance "Ok, c'est la facture électronique, c'est super et tout, mais vous n'êtes pas maîtres de vos données, c'est nous qui les gardons." Avec une facture électronique sous DRM, je ne peux rien en faire, avec le papier, j'en suis totalement maître.

Moui enfin les factures électroniques qu'on imprime soi-même c'est pas forcément ce qu'il y a de plus écologique que des factures imprimées en gros par l'opérateur. Sans compter que l'archivage papier est très fiable face à "l'archivage" électronique, surtout quand on a perdu le fichier parce qu'on n'y faisait pas attention et qu'on doit payer 5€ pour en obtenir une nouvelle copie (alors que personne ne jette ses "papiers importants", factures et autres qu'on range avec les bulletins de salaire).

Et quand on se rappelle de ce genre de mésaventure, https://linuxfr.org/~mayotte/27792.html hem comment dire... la facture électronique me paraît tout de suite moins sympathique.

En même temps, c'est pas le sujet du journal (PHP / C++).

En même temps, il ne faut pas être grand clerc pour passer d'un exemple PHP/C++ à une comparaison entre logiciels interprétés et logiciels compilés nativement, surtout quand on prend pour exemples des langages compilés vers du bytecode généralement plus rapides que PHP.

Le cache instruction fait 32 ou 64K selon les CPUs, tu auras du mal à me trouver une application moderne qui tient dans cet espace.

oui, je me suis mal exprimé, je voulais dire qu'il faut comparer à utilisation similaire. L'optimisation des programmes montre qu'en général le cache instruction n'est pas le facteur limitant mais bien le cache de données (relis par exemple cpumemory.pdf d'Ulrich Drepper, aka "What every programmer should know about memory"). Donc supposer que le cache instruction est rempli dans les deux cas n'est pas une hypothèse aberrante, et on s'intéresse au cache de données.

Sauf que comme mentionné plus haut, le bytecode d'un langage interprété est plus compact que le code machine équivalent. Donc l'efficacité cache de ce bytecode est meilleure et non moins bonne.
Sauf que comme mentionné plus haut [dans mon post] même dans le cas d'un langage interprété à bytecode, dans tous les cas le code du langage interprété réside dans le cache de données et pas dans le cache d'instructions. Il a beau être compact, il prend toujours plus de place que rien du tout dans le cas du langage compilé. L'efficacité cache de données du code interprété est donc moins bonne et non meilleure.

L'augmentation des besoins en mémoire a d'autres effets sur la consommation que la simple consommation des barrettes de RAM (qui de toutes façons ont tout le temps leurs cellules rafraîchies qu'elles soient utilisées ou non, cf les cold boot attacks & co, et donc consomment quasiment tout le temps la même chose).

Non, l'augmentation des besoins en mémoire fait surconsommer le CPU pour la raison suivante (bien décrite par le post d'alenvers) : la gestion de la mémoire, oui, mais la mémoire cache.

Dans le cas du cache de niveau 1, généralement segmenté en deux sous-caches, instructions et données, le code compilé réside intégralement dans le cache instruction là où le code interprété sépare l'interpréteur dans le cache instruction et le (éventuellement byte)code dans le cache données. Soit une surconsommation du cache données avant même de toucher aux données réelles manipulées par le programme.

Quand on sait ensuite que les accès au cache de second niveau se comptent en trentaines de cycles au minimum, il ne faut pas longtemps pour comprendre que la surpression sur le cache L1 entraîne un surnombre de cycles inutiles rien que pour la gestion des données réelles du programme !

Et ceci est totalement indépendant des calculs supplémentaires induits par l'interprétation des instructions (décoder en soft des instructions alors qu'un processeur fait ça très bien en matériel pour son langage induit également une perte de temps énorme). Le goulot d'étranglement des processeurs modernes réside dans les accès à la mémoire, pas dans le calcul.

Malheureusement cette page souffre du manque de lien vers les outils linguistiques, qui sont très utiles pour bon nombre de gens.

Si cela avait été un logiciel clé de MS, ils n'auraient pas lâché aussi facilement.

Ils ont d'ailleurs dû modifier l'outil afin qu'il ne soit plus lié à certaines bibliothèques importantes pour eux genre .Net & Co.

comme je ne savais pas ce ue signifiait PGO, voici le résultat de quelques recherches : PGO est l'acronyme de "Profile-Guided Optimization", c'est -à-dire que le programme est compilé une première fois avec des options de traçage d'exécution, puis exécuté sur une série de tests représentatifs de l'utilisation courante du programme, puis recompilé en tenant compte de ces informations.

ça permet notamment que le compilateur se concentre sur les blocs de code les plus fréquemment utilisés, en connaissant leur utilisation (par exemple faut-il dérouler les boucles ou non ?), de bien placer en mémoire les blocs de code en fonction des branches prises afin d'optimiser les accès mémoire (si le test du if est fréquemment faux, il vaut mieux placer le code du else directement à la suite du if, afin qu'il soit déjà en large partie dans le cache), etc. etc.

Voila, Windows 7 sur un Celeron M 1.3Ghz et 512Mo de RAM, pas mal moins puissant que ton eeePC 701, et comme la video le montre, ca tourne tres bien.

Tu oublies deux choses :
* l'eeePC 701 a un processeur à 600 MHz (900 bridé à 600), qui n'est pas d'une génération ultra-récente (bon ok un Celeron-M 1.3 date aussi un peu, mais bon c'est pas dit qu'il ait pas une génération d'avance)
* faire tourner windows 7 tout seul, c'est pas vraiment utile. Le monsieur parlait aussi de openOffice, the Gimp, inkscape, Firefox...

La difficulté de brider les connexions UDP n'est as forcément technique, mais aussi politique : si les FAI se mettent à filtrer les flux UDP chiffrés qui sortent sur des ports exotiques, ça va râler ferme chez les joueurs en ligne, les mêmes qui achètent les lignes chères avec un ping de la mort qui tue. Idem avec les flux du style voIP (skype & Co) ou streaming...

Je ne dis pas le contraire, seulement je ne m'étonne pas du tout que ce message n'ait aucun effet et soit plutôt mal perçu.