freem a écrit 4918 commentaires

Désolé, je n'ai pas dû comprendre ce que tu voulais faire exactement. Tu veux faire un fork de Firefox avec tes histoires de build pour n'avoir que des fenêtre seules.

Ce n'est pas uniquement le problème des fenêtre seules, mais le fait que j'aie la sensation que firefox est devenu un bloatware.
Honnêtement, je peux comprendre que les onglets existent par défaut. Je suis pas futé, certes, mais pas débile au point de ne pas savoir qu'il s'agit d'un prérequis pour 99% des utilisateurs, surtout que, forcément,la plupart des gens utilisent un WM classique.

Le build que j'espère faire est un build minimaliste, qui ne se résume pas à l'absence d'onglets. D'ailleurs, si tu avais tenté de compiler, tu saurais que firefox ne propose aucune option (et je l'accepte en plus) permettant de se passer de la MDI (hum… certes, MDI sérieusement handicapée en fait, mais peu importe).

Je t'indique une piste qui t'évite cette pénible étape et tu n'es pas encore content ??

Yep. Parce que le problème que j'ai est que FF consomme plus de ressources qu'il ne le devrait. Non, je n'ai pas 5000 onglets (à peine 10-20) mais clairement, FF est long à lancer, et ça me gêne, parce que c'est le cas même quand je veux juste voir une ressource locale.
Et pour tenter de corriger ça, je ne connais aucune autre manière que tenter d'identifier les points de ralentissement. Sauf que, pour ça, il me faut réussir à compiler un code assez minime pour que je puisse comprendre ce qui consomme tant.
C'est impossible avec FF. Il suffit de compiler avec des options fournies par le configure lui-même, pour que la compilation (longue, je le rappelle) foire lamentablement, et pas au ./configure, mais bien au make!!!

Je me trompe sûrement sur le principe du libre, mais mon sentiment est que FF utilise l'argument du LL comme une lessive utilise l'argument du blanc…
Maintenant, pourquoi je m'acharne à tenter d'utiliser gecko, alors que je pourrais utiliser webkit ou blink? Pourquoi recompiler FF et pas un de ses concurrents? Peut-être pour le troll, je laisse les lecteurs qui ont lus jusqu'ici en juger.

Tu as entièrement raison. Jamais je ne demanderais à un logiciel mainstream d'aller dans la direction contraire de ce qui m'a fait l'adopter face à IE il y à longtemps.
Je ne dis pas qu'il serait souhaitable qu'ils désactivent les onglets par défaut, je ne suis pas stupide à ce point.

Par contre, en rapport avec la section de moi que tu as citée, je me permets de dire que je trouve illogique le fait de ne pas pouvoir activer/désactiver des fonctionnalités en fonction du site, voire, mieux, et chose qu'aucun navigateur à l'heure actuelle ne propose, d'isoler les groupes d'onglets, afin de permettre de se connecter avec plusieurs sessions sur un seul site (non, ce n'est pas si inutilisé, notamment quand on à besoin de consulter des données sous diverses identités… mais c'est un truc de dev, qui m'oblige d'installer plusieurs browser pour le moment. Forcément, je ne suis pas dev web, il y a, j'espère, plus simple…).
Par exemple, le javascript, qui est quelque chose qui me semble extrêmement dangereux pour l'utilisateur qui souhaite être libre.
De là sont nées des extensions telles que ghostery, qui, du peu que j'en comprend, peuvent bloquer le contenu importé de sites externes (un site A importe de l'exécutable, potentiellement dangereux, d'un site B, ce contenu est exécuté sous l'identité de A).

Voila, un exemple de plugin qui corrige un évident manque de fonctionnalité du navigateur de base (tolérance site par site, aux cookies, JS, et autres plugins type flash).
Je parie qu'il existe aussi des extensions qui désactivent des fonctionnalités qui ne devraient pas faire partie du cœur de FF, genre l'affichage par défaut des sites les plus visités quand on créé un nouvel onglet. Ce type de… fonctionnalité… devrait être un plug-in. Activé et installé par défaut, pourquoi pas, mais certainement pas linké dans le cœur de FF.

Je suis peut-être le seul, mais… à une époque, j'utilisais beaucoup les logiciels basés sur des plugin (miranda IM, firefox, notamment). Je considérais qu'il était normal que ces logiciels ne fassent quasi rien sans plugin, parce que leur philosophie était basée sur le fait que le cœur de ces outil était ultra-spécialisé. Rien, strictement rien, n'interdisait (et d'ailleurs miranda IM le faisait) que l'installation par défaut installe et active les plug-ins les plus communs, mais il restait possible de les désactiver, voire de les remplacer.
Mon opinion, peut-être erronée, est que FF était dans cette philosophie mais qu'il en est parti.
Plutôt que de faire un cœur hyper modulable, avec des fonctionnalités basées sur des plug-ins, plutôt qu'en dur (oui, je sais, un plug-in à aussi un impact sur les perfs) FF à choisi une direction que je suis incapable de comprendre, et de soutenir, qui me semble être celle de tenter de concurrencer des entreprises. Dommage: mozilla n'est pas une entreprise, et en tant que projet libre, ayant (ou ayant eu, parce que je pense que de moins en moins de gens les soutiennent) une réputation des plus honorables, cette organisation est en train de se couper de la force du libre: les contributions externes.
Pourquoi?
Parce qu'il est devenu impossible de compiler FF sans une connaissance interne de ce logiciel (qui est le phare de mozilla), et parce que les fonctionnalités non-critiques semblent ajoutées directement dans le cœur plutôt que de profiter de l'architecture de plug-in qui à fait la force de FF.

En tout cas, c'est ce je pense.

Super. Devoir aller chercher dans l'océan about:config une valeur qui devrait être accessible via l'ihm… enfin, peu importe.
Je ne dirais pas non plus ce que je pense du fait de devoir ajouter des extensions pour désactiver/supprimer des fonctionnalités. Normalement, le but d'une extension, c'est d'ajouter, et quand ça deviens juste un moyen de faire des workaround, c'est qu'il y à, selon moi, un problème.

Pour le build, non, il ne suffit pas de les suivre à la lettre.
Et c'est aussi la première fois que je vois un système de build qui n'est pas capable de localiser des fichiers appartenant au projet lors de la compilation (j'ai tenté de modifier le source pour franchir cette étape, mais j'ai ensuite une erreur de linkage).
Chez moi, en désactivant toutes les "fonctionnalités" qui intègrent le support du son et/ou de la vidéo, j'ai encore des dépendances à webm qui traînent.
Je n'ai pas un système exotique (debian stable), je veux juste un browser léger qui ne fasse pas le café (il y à pas mal de pseudo fonctionnalités qui me sont inutiles. Bien sûr, je peux (parfois, pas toujours, et rarement de manière simple) modifier la config, mais ça ne règle pas le problème: le code est toujours là, même s'il dort il peut être source de bugs, ou pire.

Si vous doutez de l'exactitude des calcules j'avoue que le plus gros problèmes a été les chiffres a virgules et la précision d'affichage car un:

1.0002 + 2

peut facilement se transformer en:

3.00019999999999

suivant la précision choisis dans un appel a sprintf().

C'est normal, de ne pas avoir de résultats précis quand tu utilises des nombres flottants.
C'est un sujet que je ne maîtrise personnellement pas, donc je vais éviter de risquer de dire des conneries: wikipedia sera plus instructif que moi.
Toujours est-il que si tu veux manipuler des nombres à virgule en C, tu es probablement mieux à te trouver ou te faire une lib de manipulation de nombres qui ne se base pas sur float et double.

Pour ce qui est d'avoir un avis sur ton code, voici le mien, que je vais diviser en 2 parties: objective (défauts du code), subjectifs (conventions, habitudes, etc):

Objectivement, ton code:

• est en franglais. Soit tu codes en français, soit tu codes en anglais, mais évites les mélanges, ça ne fait qu'ajouter à la confusion.
• est monolithique. J'ai l'impression que toute la logique se situe uniquement dans le fichier contenant la fonction main. Tu devrais séparer ton code en unités logiques.
• se répète trop. J'ai l'impression que tu répètes les mêmes blocs de code pour chaque instantiation de structure (ou est-ce un tableau?) de type, par exemple, "Operation": operande_1, operande_2, result.
• tes fonctions ne sont pas assez spécialisées. Elles manipulent des données provenant de nombreuses sources, généralement des variables globales.
• abuse des variables globales. Ces variables sont à éviter: elles rendent le code très difficile à maintenir, car on ne sait jamais quelle fonction à, ou non, des effets de bord et où s'arrêtent ces effets de bord.
• ne vérifie pas que les appels aux fonctions se sont bien passés, alors qu'il utilise ensuite des structures allouées de cette manière. Attention aux crashs!
• n'est pas documenté.

Pour corriger ces problèmes, en gros, il te faut fracturer ton code.
Pour chaque structure, tu dois implémenter un jeu de fonctions qui seront les seules à manipuler la structure. Ça peut sembler contraignant, mais c'est la seule façon de garder ton code maintenable.
Ces fonctions ne doivent faire qu'une et une seule chose. Soit elles libèrent des ressources (mémoire, accès fichier, contrôle graphique, je sais pas), soit elles les allouent, soit elles manipulent les membres de la structure. J'ai pour standard personnel de ne jamais dépasser les 50 lignes par fonction. Quand je les dépasse, je réfléchis: ais-je mis un commentaire pour expliquer un bout de code (qui devrais donc être dans une fonction séparée, probablement)? Est-ce que je manipule des données de plus d'une structure au sein de la même fonction? Ais-je des pattern de code qui se ressemblent? Si je peux répondre oui à l'une de ces questions, alors c'est que ma fonction est mauvaise et je la refond. Si je répond oui à toutes, alors je vire directement le code et je recommence. Je n'ai pas peur d'avoir des fonctions qui ne contiennent que 3 lignes.

Côté subjectif:

• pas de versionning? Tu devrais t'y mettre, ça fait gagner un temps fou… à condition de garder à l'esprit de faire des commit minimaux et très fréquemment.
• des majuscules dans les noms de fichier/dossier. Ça peut poser des problèmes, parce que tous les systèmes de fichier ne sont pas sensibles à la case.
• aucune instruction pour compiler, un script d'install qui utilise sudo, aucune liste de dépendances. On ne peux pas tester sans devoir lutter pour comprendre ce que tu utilises? Désolé, j'ai la flemme. Si les Makefiles te soulent, ce que je comprend, il reste quand même de nombreuses alternatives: cmake, scons, et plein d'autres.
• d'habitude, on utilise src pour Source, entres autres.
• tu as une image au milieu de ton code source.

Je pense avoir fait un tour rapide. Ce n'est pas exhaustif, mais travaille déjà sur les points objectifs.

Honnêtement, plus le temps passe, et plus j'essaie d'avoir le moins d'onglets possibles, le moins de logiciels supportant cette fonctionnalité.
Parce que je considère que c'est le rôle de mon gestionnaire de fenêtre, tout simplement. Au final, je suis gêné par la manie qu'on les navigateurs d'être mono-instance, je suis aussi gêné par les outils qui utilisent des panneaux, ou le fameux MDI parce que ces choses sont en conflit direct avec mon window manager (en tuile) et le fait que j'aie plusieurs écrans.

Du coup, on peut se demadner pourquoi j'ai râlé… si j'essaie de retreindre mon usage des onglets, après tout, c'est débile. Sauf que, encore une fois, les browsers intègrent un WM. Et tant qu'à en intégrer un, qu'au moins ils le fassent correctement.

Donc, non, je n'irai pas faire de rapports de bugs. Je vais plutôt essayer de compiler moi-même, puis, si un jour j'arrive à compiler, virer les fonctionnalités qui me gênent (et faire un foutu rapport d'erreur sur le fait que l'usine à gaz de compilation de FF c'est une saleté incapable de gérer ses propres options correctement), par le code. Je vais au moins essayer, parce que j'ai été déçu par les browser minimalistes.

Ça ne facilite pas que l'entraide, mais aussi l'utilisation optimale du logiciel.

Si je ne sais pas qu'un traitement de texte peut faire des sauts de pages quand je fais de petits documents de 2-3 pages, je vais m'emmerder à faire pleins de retours à la ligne. C'est chiant et moche, mais ça marche. Si je dois arriver à 15 pages de cette façon pour qu'une icône arrive de nulle part pour m'indiquer qu'en fait, je me suis fait chier pour rien, c'est… disons, dommage.

Quand je programme en C++ en utilisant les outils qui ne sont pas présents pour des raisons de compatibilité avec le C (par exemple, les auto_ptr/unique_ptr, les cast propres, etc), le compilateur me préviens souvent quand je vais faire une erreur (et encore plus depuis unique_ptr).

Par contre, quand j'utilise la STL pour rendre du C (histo) plus lisible, plus simple à maintenir, il ne me spam pas de warning parce que j'utilise des pointeurs.

Le C++ donne le choix, d'avoir plus de sécurité que le C, ou pas.
Par contre, si tu veux dire que le C++ devrais warn quand on utilise des cast C-style, des scanf, des printf ou des pointeurs nus… je suis partiellement d'accord.
Il ne reste maintenant plus qu'à définir quel est l'héritage du C que l'on doit considérer dangereux. Tâche titanesque si tu veux mon opinion, parce que personne ne sera d'accord (surtout compte tenu du fait qu'en C++11 on était encore obligé d'utiliser des pointeurs nus. Je n'ai pas regardé si C++14 à un équivalent de shared_ptr pour les unique_ptr. Et personnellement, je n'apprécierais pas que *printf me génère des warning, je me sers souvent de ces fonctions, et elles ne supportent pas les std::string. Cout est plutôt une alternative à puts, amha).

Il est plus simple de trouver des machines avec un port série qu'avec un port parallèle, de nos jours.
Le port //, plus personne ne l'utilise, alors que le port série à encore une utilité, lui (même si je doute qu'on puisse encore en trouver sur des PC portables, mais bon).
Le //, à part pour les imprimantes, je ne l'ai jamais vu servir à quoique ce soit, alors que le port série est encore utilisé de nos jours, entres autres pour configurer les routeurs/switch paramétrables.

Je vois.
Chacun son opinion sur ce point.

J'espère que l'auteur en reparlera quand Rust sera utilisé en entreprise pour autre chose que des PoC, et qu'il aura quelques versions stables historiques avec lesquelles rester compatibles.

Mon opinion sur le fait que le C++ ne me casse pas les pieds dès que j'utilise un pointeur, c'est que c'est pas mal: ça me permets d' "objetiser" du code C qui aurait gagné à être C++ (genre, les trucs qui jonglent avec des chaînes de caractères).
Rust ne le permettra pas, c'est un choix. Si on peut avoir de nouvelles applications from scratch plus efficaces, avec un langage moins complexe que C++ mais malgré tout compilées (je reste persuadé que le natif est plus efficace que l'interprété, et que ça à son importance), alors c'est une bonne chose.

Me semblaient qu'ils disaient qu'Internet c'est le réseau des réseau, et là, on à bien un réseau connecté à un autre réseau, non?

Rust m'intéresse beaucoup.

Quand il sera en version stable, peut-être que j'abandonnerai le C++ pour lui, mais en attendant, tant que je peux lire qu'«il est déconseillé de se fier aux versions stables» pour cause de développement trop rapide, hors de question.

D'ici que Rust soit stable, il est possible que C++ ait corrigé ses défaut, tout en étant standard ISO et rétro compatible…

Au passage, depuis C++11, il n'y à plus de raison de manipuler tant que ça les pointeurs nus.
Ceci, par exemple, n'est pas du C++11:

#include <stdio.h>
int *bar(int *p) {
    return p;
}
int* foo(int n) {
    return bar(&n);
}
int main() {
    int *p1 = foo(1);
    int *p2 = foo(2);
    printf("%d, %d\n", *p1, *p2);
}

Ce n'est que du C. Il n'y à strictement rien qui soit typique du C++ la dedans, et encore moins de C++11!

Ah merci.
Quand même dommage, voire stupide, de masquer une fonctionnalité qui pourrait servir à tout le monde pour s'organiser.

Et de ce que je peux voir, c'est nettement moins utilisable que les groupes d'onglets auxquels je suis habitué (en gros, tu fais glisser un onglet sur un autre, ça crée un groupe, que tu peux replier ou étendre. Simple à utiliser, instinctif, et jamais caché même avec juste 4-5 onglets).

Peut-être ne suis-je juste pas assez habitué, ou peut-être que firefox n'est pas intuitif. Question de goûts, aussi, je suppose.

Que fait de plus, exactement, la SFML? Et que veut cibler la SDL? Et la SFML? Je parle des libs pures, hein, bien sûr. Je sais que la SDL en fait beaucoup moins, mais pour moi, c'est aussi une de ses forces.
Less is more, comme ils disent.

Pour moi tu n'a pas été qu'un peu trop vite, mais beaucoup, bien que je ne dénigre pas le fait que la SFML se soit très nettement améliorée depuis la v2 (franchement, la v1… j'ai essayé de m'en servir, mais j'ai arrêté quand j'ai constaté l'impossibilité de savoir la surface utilisée par un sprite). Enfin, je n'ai pas non plus trop insisté avec la v2, je ne me suis pas relancé dans un projet graphique depuis pas mal de temps.

Je n'ai rien à droite du gros (de l'énorme plutôt) '+' à droite de la barre des onglets… Iceweasel 31.3.0, p'tet une diff d'avec FF?

Oui, mais ce sont d'autres lib. Je parlais de la SDL pure moi :)

Même si c'est vrai que c'en est le cœur, la SDL ne gère pas que ça, ou alors ils en ont enlevé (je ne connais pas la v2).

Je cite la référence de la 1.2, au niveau des catégories.

Initialization
Video
Window Manager
Event Handling
Joystick
Audio
CDROM
Threads
Timers

Que ce soient les timers, les cdrom, les threads ou l'audio, ce n'est pas "juste le graphisme".
La seule chose qui manquerait à la SDL, si elle voulait rester «bas niveau» mais en même temps être «complète», ce serait le réseau.

La SFML n'est pas, à mon avis, totalement dans la même catégorie. Elle est plus haut niveau (gestion de l'openGL, des formes, des fontes, etc) ce qui peut être à la fois un argument en faveur, ou contre elle (pour moi, c'est plutôt en faveur, compte tenu du fait que la SFML est quasi uniquement orientée jeux vidéo. En tout cas, je ne connais aucun logiciel qui ne soit un jeu qui l'exploite, contrairement à la SDL).

Pas mal, j'avoue que je n'avais pas pensé à cliquer droit sur un champ de recherche.
Trop habitué peut-être à utiliser la gestion des moteurs pour gérer des moteurs :)

Et pour les gens comme moi qui associent un mot-clef à chaque moteur utilisé

C'est mon cas aussi.

La petite flèche à droite a un menu "Tab Groups". Si tu y vas souvent, on peut aussi ajouter l'icône dans la barre d'icônes via le menu de personnalisation.

Je vois pas là. La flèche à droite de la barre d'URI? Y'en à 2: une pour valider l'URI, l'autre pour l'historique… c'est tout.

Bouton droit sur un onglet, "Pin tab" (en français c'est "Épingler l'onglet", si je me rappelle bien).

Exact. C'est récent non? La dernière fois que j'avais regardé ça n'y était.

Gecko, comme déjà dit.

Déjà fait mon mea culpa sur l'oubli.

Blink et Webkit sont en fait assez différent […] mais certainement au niveau de l'intégration avec les autres briques du navigateur

Ça m'intéresse. Plus d'info sur cette différence certaine?

Bha…au moins Gecko ?

Je savait qu'il m'en manquait un… j'ai réfléchi pendant bien 2 minutes en plus… mea culpa (surtout que c'est le sujet du journal… facepalm ).

Le système de la barre de recherche de Firefox actuel/ancien permet simplement l'ajout parmi une liste déjà pas mal

Très insuffisant pour moi. Mais bon, je dois utiliser opera depuis la version 9 ou 10 je crois (j'ai connu la dernière version qui était encore supportée par free download manager je crois que c'était la 9). Le confort on s'y fait vite.

après il est en train d'être plus ou moins refait actuellement

Pas trop tôt. S'il pouvait enfin être possible d'ajouter/modifier les moteurs à partir de la boîte de gestion (par modifier, j'entends être capable de modifier l'URI de référence, au minimum. Le nom, à la rigueur… peu importe au fond), pas juste le mot-clé.

Je suis d'accord ça serait plus cohérent dans un client Mail.

Mouai, et encore.
Enfin bon, c'est le genre de choses qui font que je considère que FF réunit les pires côtés du bloatware et du logiciel light: il est lourd comme un bloat avec des fonctionnalités très ciblées, et n'intègre pas les fonctionnalités qui seraient utiles à l'utilisateur du WWW (firebug, hello vs contrôle des cookies/JS/etc au site par site, par exemple ou la possibilité de grouper/épingler des onglets --quoique je ne sache peut-être pas simplement le faire, hein, ça me surprendrai pas-- comme opera le permets, ou la possibilité de facilement modifier/ajouter un moteur de recherche custom --la dernière fois que j'ai essayé, je me suis retrouvé à devoir télécharger des extensions… super, mais si ça existe pas encore pour mon site préféré, je fais comment?).

Bref, je pense que les seuls et uniques avantages de FF sur sa concurrence à l'heure actuelle, c'est:

• d'utiliser un moteur de rendu différent et malgré tout efficace
• de donner la possibilité (bien que ce ne soit pas facile) de télécharger le code source, et peut-être de compiler (je n'ai pas encore réussi, mais pas eu le temps d'essayer de la semaine)

C'est pour ça que je sais que je finirai par utiliser FF quand opera 12.xy sera vraiment devenu inutilisable. Si je ne trouve rien de mieux entres temps. Dommage, que les WWW-browsers soient les logiciels les plus utilisés, et que les moteurs de rendu utilisables pour des tâches normales (afficher du HTML statique, des images statiques, et exécuter du JS, pour simplifier) soient les trucs avec le moins d'alternatives existantes, quand même. Enfin, je n'ai de chiffres, c'est juste une impression (plus que 2.5 moteurs encore vivants: IE, webkit et son fork blink, mais je ne suis pas sûr qu'ils soient si différents que ça dans les faits. J'en ai oublié?)

Ça n'est pas simple de trouver une killer feeature

Non, et ça ne rend de toute façon pas premier, sinon opera serait bien mieux classé sur le desktop.

Regarde Opera. Depuis qu’il est passé à Blink, beaucoup d’utilisateurs sont très déçus. Perte d’innombrables fonctionnalités. Pourtant le moteur est au top, c’est celui de Chrome.

En effet, je n'apprécie pas les nouvelles moutures perso. Maintenant, en réponse à un mail de ma part disant qu'il ne semblait plus maintenu qu'en beta sur linux, quelqu'un m'a indiqué que je me trompais (il semble que le répo ait changé… -.-') et que le plus récent était son préféré.
Donc, les avis divergent.

Après, c'est l'intérogation sur les priorités pour alourdir FF de fonctionnalités "extension" comme Firefox Hello par rapport à des refus de bêtes formats d'image (animées ou pas) qui fait surtout bizarre.

Exact. La plupart des gens n'ont aucune utilité de firebug, par exemple (la plupart ne font que surfer), et perso je trouve insupportable la page blanche qui liste les sites sur lesquels j'ai été récemment.
À côté de ça, on à l'obligation d'utiliser des extensions pour bloquer le JS sur une base site par site, alors que ce serait bien plus utile à bien plus de gens en standard, ainsi que, comme tu l'indiques, les formats non supportés.

On va dire qu'il y a une stratégie derrière, juste qu'on ne la comprend pas.

Certains doivent la comprendre, j'imagine.

Malheureusement, le « meilleur » dans ce domaine est encore Opera… C’est le seul avec le quel je n’ai jamais eu à jouer avec les -moz -webkit -* …

Me semblait que les versions depuis la 13 utilisent le fork de webkit, tout comme chrome? (ainsi qu'une IHM des plus douteuse à ce que j'ai cru voir… mais bon)

Dans ce cas, le plus simple et probablement efficace (dans le sens ou, au moins, si le routeur se casse la gueule à cause de l'excès de traffic interne du LAN, au moins le LAN sera toujours fonctionnel, et ça ne devrait pas trop ralentir le LAN), c'est d'utiliser un switch paramétrable, sur lequel tu configure la patte vers le routeur pour qu'elle récupère l'ensemble des paquets transitant par le switch.

Mais, franchement, ça n'a aucun intérêt (dans le cas d'un réseau domestique): le rôle d'un routeur, c'est de diriger les paquet d'un réseau vers un autre réseau, quand c'est nécessaire. Typiquement: quand on veux accéder à internet.

Ah, sinon tu peux aussi utiliser un hub, mais pour en trouver un de nos jours, ça risque de pas être facile. Et tu auras une belle perte de perf à cause des collisions, qui sont la raison qui fait que le switch fait office de gare de triage.

Encore une fois, pourquoi veux-tu faire passer la totalité des paquets par le routeur? Pour faire une sorte de firewall universel? Juste pour intercepter le traffic? Ou peut-être, comme je le pense, n'en as-tu aucune idée?