Batchyx a écrit 1261 commentaires

Si tu à un moyen automatisé pour détecter de manière certaine que ton AP à été acheté en France et qu'ils fonctionne avec les canaux français avec le firmware de base (le constructeur à sans doute testé son matos final avec la régulation française lui-même), je pense qu'ils seront intéressés.

Le problème est dans le « certain ».

Le problème est plus complexe que ça, et c'est pas comme si le sujet revenait pas tout les mois sur certaines mailing lists.

Ce qu'il y a dans l'EEPROM, ça indique (entre autres) pour quelle régulations la carte à été testée. Si la carte n'a pas été testée avec les régulations françaises, personne ne peut garantir que la carte, lorsque tu la met sur ton canal 13, ne va pas se mettre à déborder sur les bandes de fréquences à coté ou, de manière générale, à foutre le boxon chez les autres. Pareil avec des puissances plus élevée.

Du coup, ce n'est pas en disant à la carte de se mettre sur telle fréquence avec telle puissance d'émission autorisée en France que la carte va respecter la législation française. Et étant donné que les fabriquants et les développeurs de pilotes sont térrorisés par tout ce qui est légal, il n'y a pas vraiment d'autres solutions que de ne pas autoriser le canal 13 sur ces cartes.

Mais après, ça soulève une autre question: qui à déjà vu des ath testés avec les régulations françaises ? Moi pas.

Je vois pas ce qu'il y a d'illisible dans ton code. Ce n'est pas parce qu'on connais pas sa bibliothèque standard¹ que c'est forcément illisible.

Après si il y a ça sur trente lignes dans une seule fonction, son code est illisible, et il faut séparer ça en plusieurs fonctions. Tu ferais la même chose si tu voulais traduire ce code en C.

¹ Toutes les fonctionnalités de boost utilisées dans cette ligne sont dans C++11.

Si tu utilise GCC ou Clang, compile avec -Woverloaded-virtual. Ça générera des warnings dans ce cas. Peut-être même un peu trop.

Boost::Variant, c'est une « union »¹ et un entier pour dire quel type est actuellement utilisé, rien d'extrêmement compliqué. C'est comme la réimplémentation du RTTI avec un énum, sauf que c'est vérifié par le compilo, qu'il n'y a pas d'héritage et que ça permet d'utiliser des templates dans le visiteur. Et en plus, le code est déjà écrit (sinon au pire c'est pas bien compliqué à réimplémenter pour des cas spécifiques).

¹ Pas vraiment une union, car Boost::Variant supporte aussi les types avec des destructeurs et des constructeurs par copie qui lancent des exceptions, de manière assez poilue.

Moi si on me disait aujourd'hui que je devais représenter une structure arborescente, et que je ne peux pas faire autrement (genre par exemple, j'ai vu des arborescences compliquées parcourues par des visiteurs, sauf que l'arborescence était statique…), je me poserait pas trop la question : boost::variant et boost::apply_visitor. Si quelqu'un à une autre méthode où le visiteur peut gérer plusieurs types avec une méthode template, je prend.

Après reste la question de comment l'utiliser: un boost::variant<A,B,C...> avec A, B, C contenant des pointeurs vers des variants, ou boost::variant<std::unique_ptr<A>, std::unique_ptr<B>, std::unique_ptr<C> >. Chacun ayant ses inconvénients.

Parce que bon, le coup de forcer ses types à être polymorphiques pour utiliser la RTTI ou de la réimplementer avec des énums, c'est un peu limite quand même.

C'est la même chose qu'en Java: ça sert à détecter les surcharges involontaires. Par exemple

struct Base {
    virtual void traiter_truc(Truc& truc);
};

struct Derived : Base {
    virtual void traiter_truc(Truc* truc);
};

Ça compile parfaitement, mais Derived::traiter_truc() ne redéfinit pas Base::traiter_truc(), et si on active pas les warnings qui vont bien dans son compilateur (qui sont chiants car parfois, c'est voulu), on s'en rend compte qu'à l'exécution… ou pas.

Si Derived::traiter_truc était marqué en override, il y aurai une erreur de compilation.

la réduction de la consommation en veille c'est franchement l'argument spécieux. Ca représente une goutte d'eau dans l’océan.

Si tu est sur batterie, c'est loin d'être le cas.

Personnellement, j'aime pas quand j'hiberne avec 50% de batterie restante pour remarquer une semaine plus tard quand je le rallume qu'il n'en reste que 30%, tout ça à cause d'une hibernation hybride pour gagner quelques secondes à l'allumage. Moore fait que c'est toujours à ce moment là qu'il n'y a pas de prise de courant à proximité.

Cela reviens au même: Tu remplace juste le mot de passe par un mot de passe haché, mais qui reste stocké en clair et dont la connaissance est suffisante pour s'authentifier.

C'est (presque) pareil que l'authentification Digest de HTTP.

Les pools, normalement, sont utiles lorsque tu alloue et désalloue souvent, mais que le nombre d'instance reste borné à une faible valeur. Les pools vont allouer plus de place que nécessaire, c'est normal. Ils sont la pour privilégier les performances au détriment de la consommation mémoire.

Si tu veux à la fois des performances et une faible consommation mémoire, il n'y a rien de magique, l'allocateur par défaut fait déjà un bon compromis.

Je ne sais pas ce que fait ton programme, mais à mon avis, il faudrai profiler avant d'accuser l'allocateur mémoire. Ça, ou optimiser la consommation mémoire de ton programme (avec du copy-on-write par exemple).

Il veut dire que si tu exécute rm -rf /, / existe encore (même s'il est vide).

Cython est un traducteur vers CPython. Ça ne type aucune variable python, ça permet plutôt de mélanger des variables python (autrement dit, des PyObject*) et des variables C.

ip route add unreachable 173.194.52.0/22

Donc si un utilisateur abruti débarque et balance un rapport de bug "ton lecteur marche pas avec cette vidéo sur GoldenPrison, l'image est toute rouge", personne ne pourra débugger et tester ?

Plus sérieusement le salaire moyen n'est pas forcement le meilleur outils d'analyse étant donnée la concentration des revenus.

Si on veut généraliser, il vaut mieux prendre quelque chose qui s'applique à 90% de la population au moins. Autrement dit, le premier décile, qui en 2010 est à 10 430 € annuel, soit 869.16 mensuel.

ce serrait chiffrer sans avoir la clef, ce qui est assez étrange.

Non ça l'est pas. Et quand on y arrive, ça fait autant de bruit qu'une faille de sécurité classique, parce que c'est tout aussi dangereux.

Et tu en fait quoi de ton câble avec ta tablette sans ethernet ?

Gros malin; C'est précisément la question du journal!

Il peut aussi envoyer une tonne d'ondes électromagnétiques pour tout casser.

Je doute que ça soit à sa portée de jean kevin.

Par contre, installer une application Android pour balancer des fausses demandes de déassociation en série en quelques clicks tapes pour faire chier tout les réseaux aux alentours, c'est possible depuis un moment.

Et jean-kevin a les moyens de casser du WPA, c'est bien connu…

Non, mais il à largement de quoi te faire un gros DoS dans la gueule.

Correction:

c = λ.f comme pour toute onde électromagnétique !

Et pour obtenir 7m, c'est bien cette formule qu'il à utilisé, mais avec la vitesse du son à la place de la vitesse de la lumière (d'ou sans doute le "dans l'air" qui change pas grand chose pour une onde électromagnétique).

Franchement, je doute très fort de la chose à moins d'utiliser seul une grande gamme de fréquence ou prouver que Shannon/Nyquist étaient des bras cassés.

Et tu a parfaitement raison. La prochaine norme utilise des canaux deux ou quatre fois plus gros. Ça permet d'être plus rapide quand y a personne, mais quand il y a du monde ou des murs, tu ne gagnera pas grand chose.

Il n'y a pas que Visual Studio, GCC fait ça très bien aussi quand on lui demande. C'est aussi simple que g++ header.h

Mais par contre, croire qu'on ne peut pas reconstituer un header à partir de ça, c'est un peu illusoire.

Le mieux, c'est quand tu en à qui t'expliquent que le meilleur moyen pour compresser un fichier word c'est de l'enregistrer en tant que texte brut.

tout comme échanger des biens ou des services contre de l'or n'en fait pas une monnaie aujourd'hui.

Ce n'est qu'une bataille de définitions. Si je prend la définition de Wikipedia, l'or est une monnaie.

Je pense que le bitcoin n'est pas une monnaie. Il ne sera sans doute jamais utilisé comme monnaies d'échange directe dans l'avenir.

bitcoin est une monnaie. Certes elle ne vaut pas grand chose, n'est pas stable et n'importe qui peut en créer… mais c'est une monnaie quand même.

Par contre, le bitcoin est une très bonne valeur spéculative,

Traduction: c'est une mauvaise monnaie.

tout comme l'est l'or aujourd'hui.

Non, au contraire. Personne ne peut créer de l'or, et son cours est bien plus stable que la plupart des monnaies. C'est entre autres pour ça que c'est aussi cher.

Et c'est justement parce que l'or est une bonne monnaie qu'on préfère la planquer plutôt que de l'utiliser. À la place, on préfère refiler de la mauvaise monnaie, et au final, sur le plan macroéconomique, il s'échange plus de mauvaise monnaie que de bonne monnaie.

Et il risque bien d'arriver la même chose avec bitcoin: On planquera les euros pour tout ce qui est important, et on utilisera les bitcoin pour les petites conneries. Au final il s'échangera peut-être plus de bitcoin que d'euros. Mais c'est pas pour autant que les euros vont devenir inutiles et disparaître.

Le bitcoin représente une révolution dans le sens où c'est la première fois que l'humanité donne de la valeur à des résultats mathématiques dont la seule particularité est d'être uniques, et je regrette personnellement de ne pas l'avoir compris plus tôt.

Après avoir donné de la valeur à un bout de papier avec un chiffre écrit dessus, ce n'est gère surprenant. Surtout quand le bout de papier est entre autres distribué par une machine qui accorde de la valeur à un enregistrement dans une base de donnée qui n'a absolument rien d'intéressant.