benoar a écrit 4238 commentaires

Effectivement à voir : il se tape Balkany, qui est sur le plateau. Enfin, le pire c'est que quasiment tout ce qu'il dit est vrai, et qu'on en rit ...

C'est énervant de devoir toujours "attendre". Le driver nouveau avance lentement parce que très peu de monde l'utilise !

C'était comme lorsque les devs du kernel utilisaient Bitkeeper : ils se disaient que les outils libres évolueraient pendant ce temps, et qu'ils en choisiraient un un peu plus tard. Et puis en fait non, tous ont stagné et au moment où le logiciel proprio leur a fait un coup de pute, paf, il a fallu refaire son propre outil à la va-vite. Mais le pire, c'est que ça a bien marché !

C'est pareil avec Nvidia. Déjà, moi j'ai vu un beau coup de pute avec les pilotes "legacy". Mais personne ne bronche, et garde un vieux Xorg avec. Mais bon, ne faites rien et passez votre temps à attendre ; moi je vous dis que si personne ne fait rien, la situation actuelle de nouveau perdurera encore un bon bout de temps.

Effectivement, la voix se vautre sur les accents : ça commence par "axe dère" pour accéder ... En plus, pleins d'images n'ont pas de alt, il lit l'URL. Bref, pour moi c'est un _mauvais_ exemple.

Sinon, en dehors de la critique justifiée que normalement, la personne visitant ce site aura normalement déjà le logiciel pour lire la page, il faut noter que l'audio est disponible en mp3 direct (lien en bas de la page), donc on "peut" éviter flash.

Merci pour ces vidéos, et la couverture des évènements traitant du libre dans l'embarqué (Free Electron a effectivement fait pas mal de bonnes vidéos). Ça fait de bonnes ressources pour mieux découvrir un projet.

Tu viens de trouver l'intérêt des choix par défaut ...

Ben tu vois on y arrives, tu reconnais que la moitie de la planete n'a pas de solution 100% libre.

Ce n'est pas parce que des cons ont décidé que tes idées ne leurs plaisaient pas qu'il faut en déduire qu'elles ne sont pas valables. Chacun se bat pour sa vision des choses, et pour n'importe quel libriste, selon moi, s'il a fait un bout de code dont il a le droit d'auteur, s'il a envie de le mettre sous une licence libre, alors ce logiciel l'est.

Quand au materiel, TU as du matos 100% libre, moi je te parles de monsieur/madame tout le monde, quelle est la proportion de gens qui pourraient installer une distrib 100% libre sur le PC qu'ils ont a la maison aujourd'hui et en utiliser tous les peripheriques ?

Vu la proportion d'Intel (avec ses intégrés), je pense que pas mal de monde le pourrait.

Bon, en plus t'as l'air sérieux ....

Oui, il fait du H264 en libre (via ffmpeg), comme il fait du divx ou du mp3 ... Ha oui, j'habite en Europe. Donc les brevets je m'assoie dessus. Mais ça n'empêche pas que ceux qui ont codé ffmpeg ont créé eux-mêmes de leurs petites mains ce logiciel, et l'ont distribué sous une licence libre. Ils n'ont eux-mêmes aucun accord de brevet dessus.

Pour le matériel, oui, 100% libre (sauf les firmwares, OK ...) c'est du ATI/AMD. J'aimerais bien avoir des firmwares libres, mais pour l'instant ce n'est pas réaliste, et peu de monde fait mieux.

J'ai un ton un peu agressif parce que je n'aime pas les projets où il y a plein de secrets dont on ne doit pas parler. C'est pour ça que je préfère nettement le libre : tout est public, ouvert. Pour moi, le secret c'est ce qui tue tout le développement de logiciel propriétaire, et je peux te dire que j'ai bossé dans des boîtes où plein de truc ne doivent pas être dits/transmis ; et bien c'est les pire endroits où travailler.

Sinon, en ce qui concerne ton problème, ça "m'énerve" (je sais, je m'énerve pour un rien ...) de se refuser à des solutions simples quand on a des contraintes débiles. (oui, je sais que des fois on doit faire avec des contraintes, mais là, se refuser d'accéder au shell, ça me paraît débile) Comment tes règles iptables vont-elles être "rentrées" sur le serveur en question ? Il y aura bien un programme qui va lancer iptables avec les bons arguments ? Ou appeler la librairie qu'il faut. Et ce programme ne peut pas faire de conditionnelle en fonction du serveur sur lequel il se trouve ?

peu étonnant qu'on obtienne les meilleures perfs quand on peut copier toutes les données d'un côté à l'autre en restant dans le cache...

Oui, je pense que tu as trouvé la vraie raison des chiffres de ce test.

Chaque serveur avec des milliers de lignes de filtrage, ils vont être contents.
Après, si tu veux te mettre un boulet au pied avant de trouver une solution, c'est ton problème.
En tous cas, c'est clair que le "je ne peux pas en parler directement" n'aide pas beaucoup à la compréhension.

J'allais dire ce que tu décris dans ton deuxième paragraphe : tu n'as (généralement) pas le contrôle sur la manière dont le processeur gère le cache. Tu ne peux donc rien dire quant à la quantité de données qui sera en L1. Et même si c'était le cas, que veux tu faire de spécifique par rapport à ça dans ton algorithme ? Faire des pauses tous les n octets ? (je prend cette histoire débile de pause pour essayer de te faire réfléchir à ce que tu veux vraiment mettre dans ce code pour gérer la copie "par bloc" ; car moi, je ne comprend pas du tout ce que ça change dans ton algo de savoir la taille du L1).

Bon après, sur des archis un peu plus évoluées que le x86, vu que tu as un paquet de registres pour faire la copie, tu peux effectivement essayer de t'arranger pour utiliser autant de registres qu'une ligne de cache par exemple. Tu peux aussi essayer de voir que de toutes façons ton pipeline sera plein assez vite vu que tu ne peux faire que deux load/store par cycle, ou un truc du genre, et essayer de régler ces paramètres en fonction.

Ce qui est marrant avec le lien que tu donnes, c'est que les indications de gestion de cache (accessibles uniquement pour l'Altivec) des PowerPC G4 ont disparu dans le G5 car elles ne servaient à priori pas à grand chose niveau perf. Bizarre que Intel s'y mette.

Je pense que tu te compliques la vie à mort, et que tu as des lacunes dans certains domaines, mais bon, ce n'est que mon avis.

Pour qu'une machine n'exécute pas une règle, le mieux est encore de ne pas lui donner.

Juste une remarque sur ta question 2 : que veux-tu dire par "copier par bloc" exactement ? Ça voudrait dire qu'il faut faire 16Ko (par exemple), s'arrêter, et continuer ?

Car sache que pour une copie de mémoire en mémoire, étant donné que c'est le CPU qui fait le boulot, il ne peut le faire qu'avec les instructions et les registres dont il dispose. C'est à dire que généralement, il va faire la copie 4 octets par 4 octets sur archi 32 bits. Bref, on ne peut pas faire "16Ko" d'un coup. Donc tu le fait 4o par 4o, et ça jusqu'à la fin.

Après, comme le précise Samuel ci-dessus, aujourd'hui pas mal de memcpy utilisent les instructions SIMD, qui ont des registres plus gros (128 voire 256 bits) et sont généralement architecturée pour gérer des gros débits de données.

Inconvénient avec cette méthode, il faut aligner les lectures/écritures (en plus, l'alignement est aussi très important pour le cache, vu qu'ils n'ont généralement pas une associativité de fou). Enfin, c'est aussi valable dans une ALU classique, même si on a la possibilité de faire des lectures/écritures non-alignées de manière transparente ; mais on perd en perf.

Pour moi, ce que tu veux faire se fait avec du DNAT en iptables.

iptables -t nat -A PREROUTING -d mon_relai -j DNAT --to-destination le_vrai_serveur

Je sais pas dans quel troll tu t'embarques, mais le miens le fait très bien.

Je ne comprends pas trop où est le problème. Pourquoi faire du "conditionnel" niveau shell serait impossible alors que niveau iptables ce serait faisable ? Pourquoi le "grand nombre de serveurs" changerait la faisabilité en shell ?

Tu sais, les systèmes libres, rapides et simples, ça existe. Ce n'est pas parce que tu refuses de les voir qu'il faut plonger dans le "pragmatisme" (comme Mathieu, je haie l'utilisation de ce mot dans ce sens dépravé, comme tu l'utilises).

Bon, j'ai un peu mieux compris mais alors je ne sais pas pourquoi tu t'embêtes avec des telles procédures.

En gros, tu veux faire des règles "conditionnelles" en fonction du serveur ? Plutôt que de vouloir tout faire avec des règles iptables, ne peux tu pas faire l'ajout conditionnel en shell ? Ou simplement avoir un fichier de règles communes, et un fichier par serveur pour les règles spécifiques ? (pareil, que tu copies/charge conditionnellement)

Enfin bon, si tu veux le faire à ta méthode, sache que le masquerading n'est fait qu'après le routage et le filtrage en forward/sortie (d'où le nom de la chaîne : postrouting) et que donc tu ne peux plus rien faire une fois arrivé là. Avant ça, la source de tes paquets est toujours les adresses privées de tes VMs.

Ha, et aussi, ça aurait aidé si depuis le début tu disais que tu voulais faire du filtrage _sortant_ pour tes serveurs (ce qui est beaucoup moins commun que du filtrage entrant, puisque si ce sont des serveurs, ils sont plutôt accédés que source de connexions).

J'ai beau avoir relu deux ou trois fois, je ne comprends toujours pas ce que tu veux faire. Tu ne peux pas essayer d'utiliser le même terme pour la même chose partout ? Éviter d'utiliser des tournures avec des transitions bizarres ?
Et puis, nommer les machines, et éventuellement faire un dessin.

J'ai aussi l'impression que tu fais un peu du NAT à tâton ... non ?

Bon, déjà cette phrase est prise un peu hors contexte, même si sa signification est à priori celle que tu lui donne. En tous cas, on voit un des acteurs du marché actuel qui, pendant une discussion sur un standard qui risque d'amputer une partie de son marché, balance un peu d'huile sur le feu en sortant une raison qui n'est pas vérifiable (c'est même écrit en haut du billet : ce qui est dit ici ne représente pas l'avis d'Adobe ...) Je pense donc que ça pourrait aussi bien être la vérité qu'une grosse connerie juste pour emmerder tous les autres.

Ensuite, regardons le reste du billet : on voit un mec qui essaye de faire passer Flash pour une technologie complètement "open", en oubliant complètement son passé. Et j'ai retrouvé un article d'avril 2009 le citant et sortant exactement le même genre d'arguments :
http://www.downloadsquad.com/2009/04/03/talking-open-with-ad(...)

Bref, ça plus la pique vers Apple, ça sent le trolleur de bas étage.

Encore une fois, j'aimerais te faire remarquer que ta manière "d'argumenter" est tellement gerbante que ça décrédibilise tout point de vue que tu défends.

Comment peux-tu honnêtement utiliser des arguments si fallacieux, manichéens, de si gros foutages de gueule tout en restant "sérieux" ? Franchement, tu sais très bien que ton argumentaire populiste est fait pour séduire les plus crédules, mais arrêtes rien que pour respect pour ceux qui te lisent et qui ont un peu plus de 2 de QI.

Ils ne donnent pas forcément, ils peuvent vendre à prix réduits...

Moi j'avais cru comprendre que les premières fois où tu topes, tu te fais plutôt entuber grave ...

Oui, pas de pilote libre. Pour moi c'est bloquant car s'amuser à suivre au poil de cul près les kernel/Xorg que veut bien supporter le constructeur, ça mène à rien.

Ha si, j'ai un vague souvenir que des devs externes à Imgtech devaient sortir un driver 2D libre au moins (genre Tunsgten Graphics pour le compte d'Intel, qui utilise aussi ce chip ? Je ne sais plus), mais c'était juste une annonce pour je ne sais pas quand.

Le jour où tu seras redescendu de ton nuage, tu apprendras grep et les regexp ...

Tiens, je viens de voir qu'il avait une PowerVR comme carte vidéo. Ça s'annonce mal pour la suite pour tout ce qui est graphique ...