benoar a écrit 4229 commentaires

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 ...

Moi je dirais que dans tes essais, à un moment t'as dû de tromper, faire une faute d'attention, et écrire l'initrd dans ton kernel .... (vu que d'après file, ton vmlinuz ressemble fortement à un initrd). Ça arrive des fois, l'erreur est humaine. D'où ma suggestion de reprendre celui du RPM.

J'ai dû bidouiller ya pas longtemps de l'initrd à la main, mais quand ils déconnaient, le kernel démarrait quand même, même sans lancer l'initrd. Si tu as un problème de ce genre, c'est sûrement le kernel qui a été touché. Peut-être as-tu copié des mauvais fichiers au mauvais endroit ? Essaye d'abord de recopier le kernel du RPM, ça pourra aider.

Non, ça n'est pas la vibration, juste en espèce de léger son grave, mais audible tout de même. Mes deux disques 2,5" 7200tpm sont suspendus, dans une cage sur coussinets.

Toi aussi ta définition est fausse.
Les drivers Nvidia sont compatibles "linux 2.6 (de 2.6.24 à 2.6.32, non-modifié) sur x86 avec ABI GCC 4.4" (c'est un exemple, hein). Ce qui est _complètement_ différent de "compatible linux" pour moi, car le seul moyen d'être compatible avec tous les linux, c'est de filer les sources. Il n'y en a pas d'autre.

Le jour où une boite dira que c'est compatible linux open source ok, mais pour le moment les cartes récentes nvidia sont compatible linux sans problème (et même plutôt bien)

Je suis plutôt bien placé pour te dire que non : J'ai une Nvidia, mais sur un PowerPC. J'aurais beau essayer de les retourner dans tous les sens, leur driver ne marchera pas (heureusement que des libristes "s'amusent" à coder une alternative).

Moi je trouve ça grave que les gens se prennent plus la tête pour des brevets logiciels sur un logiciel libre (et qui ne sont pas valables en Europe) que sur la fermeture du programme et du protocole. Je suis d'accord que envoyer chier les brevets logiciels n'est pas forcément la solution idéale pour qu'ils ne nous emmerdent plus, mais en contrepartie dire qu'on accepte un logiciel proprio et un format fermé ... pour moi c'est complètement contraire à l'esprit du LL.

Et encore une fois, je rappelle à tous ceux qui conspuent H264 qu'ils doivent arrêter de lire des divx et écouter des mp3. Vous ferez moins les malins après.

Si c'est pour se retrouver, comme sous Windows, avec du matériel obsolète dès qu'on change une version de l'OS, non merci. Pour moi, un matos "compatible linux", c'est qu'il a au moins un driver libre. Tout le monde ne va pas être d'accord avec cette définition, mais inciter à se retrouver avec des drivers binaires partout c'est filer droit dans le mur pour le libre.

N'importe quoi.

Entre un plugin proprio qui diffuses des vidéos dans un format fermé, et un plugin libre qui diffuse un format ouvert, mon choix est plus que vite fait.

Ou alors j'ai pas compris l'ironie, ou alors tu dis une grosse connerie.

Effectivement, le type de disque joue. Mais dans ma tour qui n'a pas beaucoup de ventilos (ou qui tournent pas vite), j'ai des disques 2,5" que je n'entend pas directement, mais qui quand on les éteint (à coup de hdparm -y) font disparaître un espèce de son/vibration grave que j'entendais juste avant.

Après, si t'habites dans un coin ou ya déjà du bruit ... (bon OK pour la musique, elle est souvent là pour couvrir un peu le bruit, mais tout de même, de la bonne musique sans le moindre peitt vrombissement derrière c'est agréable).

Faux, et ceci dépend beaucoup des gens. Pour moi, un disque 2,5" est très clairement audible. La limite que je supporte, c'est un 1,8", et encore, le "clic" qu'il fait régulièrement m'énerve.

Beaucoup de gens ont une définition de "silencieux" qui n'est pas la mienne, et qui est très distinguable par un paquet de gens. C'est pas parce que vous avez les oreilles défoncées qu'il faut annoncer que c'est "silencieux".