tgl a écrit 1743 commentaires

Rassure moi... si on veux juste brouzer le ouaibe pépère, on est pas trop déstabilisé ? ;-)

C'est quand même utile pour permettre des accès simultanés au son :
- par des applis mal fichu (le plugin flash de macromédia par exemple, qui plantait si le device n'était pas disponible) ;
- pour des cartes sons qui ne supportent pas assez de voix ;
- pour des cartes dont les drivers sont encore buggués à ce niveau.

Mais c'est vrai que dans une grande majorité des cas, on peut s'en passer. Or il me semble que kde l'active par défaut, ce qui n'est pas nécéssaire, voir nuisible.

ça serait à mon avi mieux

Héhé, voilà un faute bien à propos :)

C'est pas par flemme que la BNF ne fait pas d'OCR, c'est parcequ'elle s'intérresse aux ouvrages, et pas seulement au texte. C'est pas la même finalité quoi. Mais l'idéal serait qu'elle fasse les deux, pour qu'on ai le choix suivant nos besoins et envies.

Pour vim franchement, j'avais cherché et pas trouvé... Je rejetterai qlqs coups d'oeil ceci dit, je suis pas un killer avec mon vim, et j'ai pu rater qlq chose. Pour emacs, je le mettais dans les éditeurs +/- prévus pour :) Mais ça n'est réutilisable que si on sauve avec des espaces. Si tu as un disque dur de 1Mo, et 2Ko de RAM, tu peux faire un mode qui supprime les espaces quand tu sauves, et C-x h C-M-\ indente tout le buffer. Mais en pratique, c'est complètement inutile ... Oui, mais je trouve encore plus abhérant de sauver des tabs qui ne présentent bien que si on leur donne une taille précise, bref qui ne sont pas une marque signifiant "1 degré d'indentation de plus" comme en C, mais une simple "compression de n espaces". Enfin bon, c'est pas bien grave tout ça, je ne l'abordais que comme un gravier dans la mare du sacro-saint "faut indenter avec tabs". Un post du midi quoi...

On a causé C et python, mais moi je fais du scheme, et j'ai jamais trouvé que les éditeurs classique permettaient de l'indenter correctement. Le truc, c'est que la notation est préfixe fonction et que le paradigme fonctionnel fait qu'on imbrique beaucoup. Du coup, on à tendance à mettre les opérandes un peu longs en colonne, avec le premier qui est derrière le nom de la fonction:

...
  (and (blabla truc muche)
          (or (bidule chose fmuh)
               (sbrong glop (gluglu (plopplop 1)
                                             (coincoin 2)
                                             (panpan 3)))
...

Le problème, c'est que c'est faisable que dans des éditeurs vraiment prévu pour ça, ou alors à la main avec plein d'espaces (pas question de tabs de longueurs fixe ici, on perdrait les colonnes vu que la largeur de l'indentation dépend de la ligne au dessus). On pourrait, pour utiliser une indentation plus systématique à la C, passer partout à la ligne, mais c'est vite vraiment trop long, et moins lisible... Alors du coup, soit l'éditeur doit tout sauver avec des espaces (c'est généralement le cas), soit il doit sauver sans indentation mais en sachant qu'il y a, quand il ouvre un fichier, un décalage au début de chaque ligne qui est à déterminer par rapport à celles du dessus. Là mon vim, il gère pas ça...

j'ai quand même âs m'impression que mldonkey gene beaucoup Emule, ou edonkey, et je m'insurge contre cette histoire de partage de slot fixé à 33%...

S'cuse, mais ta phrase est pas très claire... C'est contre quoi que tu t'insurges ? L'ex-limite à 33% qui n'existe plus ou bien l'absurde polémique qui elle existe encore ?

Pour rappel MLdonkey est un client voyou du reseau eDonkey, ( upload largement perferentiel pour les autres clients MLdonkey, fil d'attente non standar, abus et surcharge des serveur, non respet des ratios up/dl etc etc ... ) et est donc logiquement bannie de beaucoup de serveur dont les plus frequentés et les mieux administrés telle que les lugdunum.

Combien de temps va-t-on se faire rabacher ça ? Mldonkey n'est pas plus aggressif que n'importe quel autre, et mldonkey n'est pas banni des serveurs, y compris les lugdunum. C'était le cas dans sa version 1.16, ok. Emule aussi à une époque à eu ses bugs et son ban (0.22b), on va pas ressasser ça 107 ans...
Ce qui est toujours vrai par contre, c'est que de nombreux mods emule ont pour principale fonctionnalité de limiter/couper l'upload. C'est d'ailleurs beacoup grâce à des mods peu fair-play que emule a pris le dessus sur edonkey à une époque, alors que le edonkeybot qu'affectionnait les boulimiques commençait à se faire bouler de partout pour cause d'agressivité. (Ceci dit, ok, rien n'oblige à les utiliser. C'est juste dommage que des plugins aient la possibilité de faire ce genre de chose)

eMule ( win32 GPL ) et son recent portage sous linux ( GPL aussi logique ), sont bien plus respectueux du reseau et de ses serveurs et en plus son systeme de score est reellement efficasse puisqu'il represente au bas mot 80% des clients du reseau eDonkey.

emule est le seul à avoir modifié le protocole, et tu parles de respect ? Le fait qu'il soit majoritaire ne lui donne aucun droit sur le protocole. Ou bien alors il est temps qu'on laisse les éditeurs de logiciels majoritaires décider pour nous de ce que doivent être les protocoles, ce que peu de gens ici souhaite je pense.

Je n'ai pas l'abitude de dessendre des projet mais MLdonkey est vraiment mauvais et peut respectueux des projet tiers, par exemple il a longtemps implementer uniquement le download, dans les branche de dev il incorpore des modules pour d'autres reseaux souvant en developpement et perturbe leur developpement et leur Beta test ( ex giFT/openFT )...

Ok y'a des trucs en dévelopement, genre pas finis avec des bugs, dans les branches de dev sur le cvs. Il ne sont pas compilés dans les distributions binaires à usage du grand public. Alors c'est quoi le problème, c'est d'avoir des trucs en devel dans un cvs public ???

Moralité MLdonkey c'est peut étre sous GPL mais c'est mal(tm)

J'en ai un peu marre ces temps ci des gens qui parcequ'ils sont les plus costauds se permettent de décider de ce qui est Mal.

Deux choses:

- la limitiation des 33% n'est plus active :

The code does exist, but has no effect... If a client is not accepted in the quota, the "add_pending_slot" function is called, whereas if it is accepted, it is the "add_pending_slot" function which is used :)
-MLDonkey


- elle donnait juste un accès prioritaire au clients minoritaires, qui étaient en difficultés le temps de s'adapter au amenagements de protocole d'emule. Si moins de 66% des slots disponibles étaient utilisés par de tels clients, les emules pouvaient avoir alors plus de 33% des slots, 100% même pourquoi pas. Et vu le faible nombre des clients non-emules, ça arrivait très souvent. C'était juste un moyen pour une minorité de s'entraider à un moment difficile, je vois pas trop le mal.

emule propose tout de meme des fonctionnalité sympatique comme le fait de pouvoir evaluer les fichiers....

Et beaucoup d'autres, c'est indéniable. Mais mldonkey a aussi de gros avantages, son côté daemon accessible par telnet/http/gui notamment. En termes de fonctionnalités, les avantages et lacunes sont nombreux dans les deux camps en faits.

De plus il essaye quand meme de garder la compatibilitee avec les autres clients.

Par contre, pour ce qui est du côté "compatibilité", disons le tout de suite c'est faux. Dernier exemple en date, la modification de la sémantique du message SlotAvailable, qui pour emule signifie maintenant qu'on a le droit de downloader, certes, mais pas plus de 1 chunk, sinon gare. Les clients n'en tenant pas (encore) compte s'en sont trouvé très perturbés qlqs temps... (mais bon, on s'adapte, et c'est entre autre ça la "emule compatibility" évoqué par le changelog).
Ou encore le ban en cas de demande répeté d'un fichier: certes c'était pas malin de le demander 3 fois, mais franchement, ça ne perturbais pas le réseau. Simplement, ça permettait de reconnaitre les mldonkey qui étaient les seuls à faire cette petite erreur, qui n'en est pas une d'ailleurs selon le protocole edonkey.
De manière générale, qlqun critiquait dans un autre post le "mauvais support de emule par mldonkey". Et moi qui croyais que c'était deux client du même protocole, edonkey...

Quand à l'ambiance dans la communauté, je te suggère de regarder du côté des tentatives de discussions entre mldonkey (le developeur) et les emuliens... Exemple: http://forums.edonkey2000.com/phpBB/viewtopic.php?t=43366(...)

Emule n'a pas créé de protocole, il a modifié celui existant de référence, càd celui d'edonkey. Mldonkey le respecte lui, sauf quand il dialogue avec des clients emule évidemment... Maintenant, je ne suis pas contre des modifications si elles sont bien intentionnées, profitables et, au moins quand elles modifient la sémantique du protocole, concertées entre les différents acteurs du réseau. Ça n'a pas été le cas, c'est dommage.

La limite des 33% qui a été proposée dans qlqs versions l'était à une époque où de telles modifs n'était pas encore reversées, ce qui faisait que les mldonkey avaient grosso-modo 20% de leurs downloads depuis des emules pour 90% de leur upload. De plus, la limite n'a jamais porté sur la bande passante, mais sur le nombre de slots alloués, donc si il n'y avait pas ou peu de mldonkey qui téléchargeaient chez toi (rappellons que c'est souvent le cas vu sa représentation chez les clients), toute la BP disponible était accessible pour les emules ou autres.

Cette limitation n'existe plus depuis qlqs versions (depuis qu'on est revenu à l'équilibre), même si la valeur (le %) est toujours dans le fichier de config.

Quand au fake d'identité, ça n'était qu'une réaction à des blocages arbitraires par plusieurs mods emule (tu sais, les "mods", la killer feature pour virer l'upload, tout ça...). Pour reprendre mon analogie foireuse avec le web, rappellons que les navigateurs libres aussi sont parfois amenés à mentir sur leur identité pour ouvrir les portes réservées aux monopolistes (le "si si, je suis un IE, laissez moi visiter votre site").

C'est comme mozilla qui est souvent en retard sur IE quant au support des extension de MS pour les standards du web... (bon d'accord, le protocole edonkey est pas un standard, mais quand même, y'a une implèmentation de référence.) De là à lui reprocher, je trouve ça un peu gros.

Pour les formats, oui, y'a eu qlqs petits changements ces derniers temps, je ne sais plus trop quoi.

Pour les idées:
- faire des "verify_chunks" des fichiers ?
- attendre... (si si, c'est souvent long)

C'est d'autant mieux que l'échange des données et la signature des fichiers chunks marche pareil, d'où {down/up}loads partageables entre les deux réseaux en fait. Et puis c'est aussi supporté par mldonkey, comme qlqs autres protocoles encore.

Perso, je préfere largement mldonkey. Le projet est aussi très actif, les fonctionnalités beaucoup plus nombreuses, et ça fonctionne aussi nickel-chrome... enfin, quand il est à jour sur les discrètes "évolutions" du protocole qu'introduisent les {l|e}mules ;-)

T'as essayé un "recover_temp" ? C'est censé être là pour ça...

<le_saviez_vous_?>
Les sous-titres des dvds sont en fait des vilains bitmaps. Heureusement, grâce à "subtitleripper", qui utilise GOCR, on peut les convertir en de gentils formats textes légers, et lisibles par mplayer et autres xines. L'idéal pour épater vos cyber-amis cinéphiles, forcement amateurs de divx en VOSTF...
http://subtitleripper.sourceforge.net/(...)
</le_saviez_vous_?>

[-1] parceque ce commentaire est vraiment niais mais [+1] parceque il pourrait intérresser ceux qui ne le savais pas, donc [0].

Un autre lien qui mériterait d'être dans la niouze:
http://www.research.ibm.com/gsal/tcpa/(...)

Enfin moi j'dis ça...

Non, c'est juste parce qu'il généralisait que j'ai réagit.

Soit. Mais avoue que tu t'es offert au passage un petit pic gratuit et sans fondement, le «une vraie distrib, pas avec un truc qui ne compte que sur les optimisations pour se démarquer».

non, j'ai répondu qu'il devrait tester autre chose avant d'arriver a une vraie conclusion.

Si tu l'avais dit sans le pic sus-cité, je ne pense pas que j'aurais eu à réagir.

Que tu l'ais pris pour un troll, c'est que tu es d'accord pour dire que la gentoo a les défauts que j'ai énoncés.

Je ne te suis pas là, mais c'est probablement sur la définition de troll que nous divergeons. Enfin toujours est il, s'il est encore besoin de le préciser, que je ne pense pas que:
- la gentoo ne soit qu'une distrib à tuner les cflags
- la gentoo soit plus instable que les autres distributions

Un systeme de dépendances est fait pour garder une cohérence au niveau de la distro. Il faut aussi qu'il te permette de parfois passer au travers de ces protections, mais ça doit etre rare et l'utilisateur doit savoir ce qu'il fait. Sur gentoo, c'est l'inverse, seul l'utilisateur qui sait ce qu'il fait peut gérer les dépendances a l'unmerge.

Ok, c'est un point de vue. Pour moi, l'important, c'est qu'il y ait les outils pour arriver à ses fins (en termes de paquets installés, de cohérence, etc.) sans tâche manuelle fastidieuse. C'est le cas sous gentoo, ça ne l'est pas par exemple sous slackware. En ça, ces systèmes ne sont pas à mettre dans le même sac comme tu l'as prétendu.

Bon, ceci dit, je me lasse un peu là. On arrête ?

> Totalement fallacieux. Relis toi: "Mon cas particulier implique l'universalité"

Et lui il ne généralise pas peut etre? ça ne fonctionne pas convenablement chez lui-> c'est de la merde


Et bah c'est pas une raison pour faire pareil. Mais effectivement, c'est un peu abusif. Mais ça ne change rien au fait que tu as sauté sur l'occasion pour troller contre gentoo, de manière encore plus abusive.

Mais pourquoi tant d'obstination à refuser l'éventualité que ce mec ait effectivement diagnostiquer correctement la présence d'un problème materiel chez lui, sur sa bécane.
Sérieux, c'est toi qui lui a vendu ou quoi ?

Ce que je dis depuis le début c'est:
- les instabilité matérielles existent, la preuve j'en ai eu.
- elles se manifestent souvent lors de l'utilisation de gcc, je l'ai constater par exemple avec une slack aussi.
- sous gentoo, l'utilisation de gcc est courante, ce qui explique qu'elles se manifestent plus courament que sur d'autres distributions.

Et tu réponds:
- les instabilités matérielles n'existent pas, la preuve j'en ai pas.
- donc une instabilité sous gentoo c'est normal, c'est parceque elle est nulle cette distro, la preuve je l'aime pas.


Quand à l'histoire des dépendances:

Euh, t'as dut mal lire, Christian Wiederseiner dit qu'il ne désinstalle jamais rien a cause du manque de cete fonctionnalité et toi, tu lui expliques qu'il existes des outils pour émuler cette fonctionnalité mais que c'est de toutes façons, géré par l'utilisateurs alors que ça devrait etre le systeme de packages.

Je trouve très bien que ce soit l'utilisateur qui _décide_ de nettoyer les dépendances, et pas le système de packages. Le tout, c'est que cet utilisateur puisse le faire facilement, et c'est le cas. Moi ça m'arrive par exemple de virer temporairement une librairie pour mettre une version de debug à la place, à la main. J'ai pas pour autant envie de virer tout ce qui en dépend, alors que ça marchera très bien à nouveau qd je la remettrai. Non, vraiment, je comprends en quoi un gain en souplesse d'utilisation peut être criticable.
Quand au fait d'avoir à mettre un pipe en une commande qui liste des choses et une qui agit dessus, je maintiens que c'est une bonne façon de faire. Et ceux que ca emmerde peuvent faire un alias. Mais en aucun cas je n'y vois une faiblesse. Ou alors, c'est tout posix qui est à revoir et il faut vite creer un énorme ensemble de commandes clôt par redirections.

je n'ai encore jamais eu le moindre probleme, mon proc est plus élevé que le sien, ma ram n'est pas de marque(mais je l'ai quand meme testé avec memtest86) donc ça ne peut venir que de la distro.

Totalement fallacieux. Relis toi: "Mon cas particulier implique l'universalité"

C'est pas trop ennuyant d'attendre plusieurs heures pour avoir le meme résultat que monsieur tout le monde?

Je n'ai pas le même résultat. D'une part, j'ai une Gentoo, et comme je l'ai déjà dit ça a bien d'autres avantages que l'optimisation du code. D'autre part, quand on compile un programme, on n'agit pas pas uniquement sur les cflags. As tu déjà essayé un "./configure --help" sur qlqchose ?
En outre, je n'ai eu à attendre que le jour (bon, d'accord, les 2 jours) où j'ai installé ma Gentoo de départ, et c'est tout. Depuis, les mises à jour ne m'ont jamais empêché d'utiliser ma machine. Je n'ai donc jamais eu la sensation d'attendre quoi que ce soit depuis, et c'est pas près de m'arriver à nouveau, puisque les mises à jours se font en douceur, au fil du temps.

Un gestionnaire de paquet qui ne gere pas les dépendance a l'unmerge, ça sert a rien, je le met au niveau de celui de la slack.

Tu devrais te renseigner, ou au moins lire sur cette page les commentaires précédents. Il y a tout ce qui faut pour gérer les dépendances dans tous les sens, même si le comportement par défaut est effectivement de les ignorer pour l'unmerge.

Qui te dit que c'est le matos?

Il me le dit. Et avec la description qu'il fait, plantages alétoires de gcc, c'est pas bien dur à croire.


> Et qu'est-ce que tu lui réponds ? "Bah t'as qu'à utiliser du code de 386, et pas lancer des trucs qui titillent trop la machine."

J'ai dit ça ou? les distros comme mdk, redhat, slack utilisent des optimisations i686

Ok, je retire le "code de 386". Reste le "pas trop titiller la machine", que je maintiens. Si on n'a pas d'emmerde à l'install d'une distrib binaire sur du matos instable, c'est parceque l'install ne la titille pas trop. Bref, on évite le problème, alors que l'install d'une gentoo, compilation oblige, met le doit dessus. En l'occurence, qd j'avais un CM instable, il me restait un slackware dans un coin de disque. Bien sûr elle marchait... sauf pour compiler un noyau.

Je suis assez d'accord avec ton bloc de TROLL. Maintenant, bon, y'a pas que mdk et slack dans la vie. Mais la distinction entre l'orientation "scripts compliqués mais avec des frontends" et "scripts simples avec vi" me parait juste. J'avais d'ailleurs quitté les rh/mdk à l'époque des 6.qqch parceque trop de choses ne se règlaient pas par clic-clic, et étaient douloureuses à faire à la main de part la complexité des scripts. J'étais du coup repassé à slackware avec soulagement. Depuis, je suis sous gentoo, où on trouve aussi cette clarté dans les scripts de config, démarrage, etc, et je n'envisage vraiment plus de repasser sur une distrib complexe comme la rh ou la mdk.

Gentoo ne compte pas sur les optimisations pour se démarquer, loin de là. Ce n'est qu'un des avantages, à mon sens assez mineur. Perso, le gros de ma distrib est compilé en -02, comme chez monsieur tout le monde, et ça ne m'empêche pas de préferrer largement cette distrib à toutes les autres que j'ai essayé avant. Tu devrais peut être jetter un oeil au gestionnaire de paquet, au système d'init, bref à tous les trucs innovants de la Gentoo avant de brandir ton troll poilu.

Qu'est-ce qu'on a là ? Un mec qui a du matos instable, comme ça arrive souvent de nos jours avec le dernier cri. Et qu'est-ce que tu lui réponds ? "Bah t'as qu'à utiliser du code de 386, et pas lancer des trucs qui titillent trop la machine." Je trouve pas ça très constructif... Et puis même avec une Debian ou autre, le jour ou on a besoin d'un nouveau noyau, on risque de lancer le machin intensif qui fait planter les pc instables, aka gcc. Fausse solution donc, essayer plutôt de règler vraiment le problème. Faut bien comprendre que un pc qui plante sur des grosse compilent, ou sur du code exploitant les instructions 686, etc, c'est pas normal. Et c'est pas un problème de distrib.

Bah toute société à des impératifs commerciaux, un objectif de rentabilité

Non.

Une société c'est une forme juridique, une personne morale, ni plus ni moins. Elle peut parfaitement ne pas accumuler les dettes même si elle ne vend rien et ne court pas après la rentabilité: il suffit pour ça qu'elle n'ait pas de frais, ce qui est le cas de la Gentoo Tech Inc. Je ne sais pas à quoi ressemble le droit américain, quelles sont les formes de sociétés et associations qui existent, mais ce que je sais c'est que _actuellement_ la Gentoo Tech Inc ressemble à ce qui en France aurait pu être une asso loi 1901. Peut-être par contre qu'elle aura à termes une activité commerciale, c'est possible, mais pour l'instant ce n'est pas le cas. Et ça ne changera rien à la distrib de toute façon.

Je soulignais juste que Gentoo était une société, contrairement à une Debian

Tu essayais de souligner que Gentoo avait des «impératifs commerciaux», ce qui est faux.