benoar a écrit 4238 commentaires

Ce qui me fait drôle dans cette histoire, c'est de recevoir une réponse contenant une adresse non routable sur internet. Et cette adresse vient, justement, d'internet (puisque je loue le fait d'être connecté à internet). Je veux bien que ce soit leur réseau, mais je ne suis _jamais_ sensé recevoir de telles adresses (sauf si j'ai un VPN par exemple, mais là ce n'est pas du "internet").

Je dirais que c'est tout à fait classique : ils ont des machines en interne chargées de router le traffic de leurs abonnés, mais qui n'ont pas besoin d'avoir une IP publique (i.e. elles ne sont accédées par Orange que depuis son propre réseau). Elles peuvent router du traffic à destination d'IP publiques sans problèmes, elles ont les routes pour. Et toi, tu ne verras normalement jamais leur adresse nulle part, et effectivement tu as raison de filtrer tout ce qui est non routable. Sauf que là tu as explicitement fait un traceroute, qui doit être la seule commande où tu verras cette machine, mais tu l'as bien demandé : ce 3è hop vient d'un paquet que t'as envoyé avec un TTL de 3, bah là machine fait ce qu'une machine normale fera : _elle_ te renvoie un paquet provenant de son adresse disant que le TTL est arrivé à 0.

En tous cas, je ne vois pas en quoi cela a pu poser un problème à ton réseau, normalement elle n'interfère en rien. Ce serait bien d'avoir le détail pour qu'on comprenne.

Sauf qu'en testing, tu peux attendre les corrections pendant des plombes. Faire rentrer un paquet dans testing est beaucoup plus long que dans sid. C'est bien pour éviter de casser les choses en allant trop vite, mais quand testing est cassée (à cause d'un bug qu'on n'a pas vu dans sid), elle met aussi longtemps à être réparée ...

D'ailleurs, à propos d'import et d'anciennes données, j'espère qu'il est aussi prévu de garder les anciennes URLs ? (au moins pour les anciens articles) C'est faisable pas trop difficilement en RoR ?

Netcraft nous indique qu'avant le squattage, le serveur était http://66.35.39.65/trac/ ...

Ta description me fait un peu penser à XCode en faisant de l'Objective C. Bon, ça doit pas être aussi haut niveau que tu l'espérerais, mais c'est pas mal quand même. J'avais particulièrement aimé le debug à la volée avec rechargement de code à chaud (sans redémarrer l'appli, bien sûr) qui a été "intégré" (i.e. renvoyé upstream) à gdb juste après, il me semble (puisque XCode utilise justement gdb). Même si les IDE "modernes" genre Eclipse doivent faire pareil aujourd'hui (mon expérience d'XCode date de quelques années déjà, il a du encore s'améliorer depuis).

Exactement pareil, dans Iceweasel, ça marchait jamais, je m'arrachais les cheveux. La solution parcellite ci-dessus me dépanne bien !

Rho putain j'ai espéré trouver un truc du genre depuis longtemps, et je n'avais jamais vu cette option !

Sur des petites bécanes qui n'ont pas flash, rien que l'affichage de cette barre faisait lagger à mort FF car la barre s'affiche en slidant pixel par pixel, faisant réafficher la page un pixel plus bas à la fois, opération super lente sur un vieille bécane ... Merci !

L'utilité étant d'avoir toujours la même longueur / syntaxe de chaîne (plus facile à parser/stocker).

Avoir toujours la même "syntaxe" d'adresse est le but de la "norme" dont je parlais : elle expliquaient comment compresser l'adresse de manière à ce qu'une adresse donnée n'ait qu'une et une seule forme. Le truc était fait dans l'optique de comparaison d'adresse. Ça permet d'avoir une forme canonique (j'avoue que je confond toujours ce mot avec "normalisé" : ton utilisation de ce mot est donc tout à fait bonne pour moi, en fait ...).

Si c'est un proxy HTTP, malheureusement tu n'auras que droit à du HTTP ...

Regarde en:Dynamic DNS pour ce qui est de mettre à jour le serveur DNS.

Comme indiqué dans le bug-report que tu pointes, le fix est déjà dans unstable ; il devrait arriver bientôt dans testing, ou alors tu peux aussi installer le paquet d'unstable (ce qui est mieux que d'installer des paquets de stable dans testing).

En tous cas, tu tombes sur le plus gros problème de testing : les bugfixs mettent des années à arriver, c'est comme ça. Moi, je préfère largement unstable.

Je connaît pas d'autre RFC qui parle du sujet, mais si tu as plus d'infos je serais heureux de corriger mon code et mon cerveau :)

Bon, impossible de retrouver le papier où j'avais vu ça ... (il me semblait que c'était une RFC ...) C'était en gros pour avoir une forme canonique d'IPv6, en explicitant les cas ambigus comme quand on a deux suites de 0 (sur 16 bits) séparés, laquelle compresser en :: (j'ai souvenir de "celle de gauche") ; qu'on "compresse" toujours un maximum ; etc. Mais bon, tant pis.

Moi j'ai déjà récupéré des Acer "HS" parce que surchauffe, et ce n'était qu'un problème de poussière. OK ça demande un démontage complet, mais après la bécane marche très bien.

chaque constructeur faisant sa sauce.

Et il est aussi dit un peu plus loin dans le thread que les constructeurs ne se cassent pas le cul à factoriser le code, et préfèrent copier/coller le code existant en rajoutant leurs modifications, ce qui n'aide pas à arranger le bordel.

Avec ça, le header REMOTE_ADDR et autres headers du genre sont remplacés par une adresse IP aléatoire générée à l'aide de la véritable adresse IP comme seed. Ainsi pour le code PHP en dessous, ça ne change rien au niveau logique, sauf qu'il ne peut avoir accès à la véritable IP du client.

Au début, je n'ai pas très bien compris ton explication, mais en allant voir ton lien, j'ai capté : tu fais un hash de l'IP, représenté également comme une IP.

Ça peut être pas mal ... Par contre, en IPv4, ça doit être facile de faire une rainbow table pour retrouver l'IP d'origine. Bon, par contre, en IPv6 ...

Enfin, petite remarque : ta normalisation d'IPv6 ne suit pas, selon moi, la RFC que j'avais vu à ce sujet (on n'étend pas tout "bêtement"). Vu que tu dis juste "following the RFC", je ne sais pas à laquelle tu te réfères.

Arrête de nous narguer !

Si t'es vraiment motivé, comme le dit ze_lionix, c'est le meilleur moyen de montrer que t'as vraiment envie de t'embarquer dans ce domaine (haha). En plus, t'auras des gens qui sont dans l'embarqué _et_ le logiciel libre. Si ça te tente vraiment, dis toi aussi que tu n'auras plus jamais l'occasion de faire ça ...

Oui, je pense, à moins de gros changement dans les drivers.

Je viens d'en apprendre un peu sur les dts/dtb tout à l'heure, t'as de la chance ...

Donc, le "Device Tree Source" c'est, en gros, un fichier qui va décrire ta board et ses périphériques. Ça réunit les informations "bas niveau" sur l'organisation des bus, les interrputions, des mapping mémoire, etc. Ça se compile donc en dtb.
Ça permet de ne pas coder "en dur" l'initialisation des périphériques dans le kernel. Je suppose qu'on peut comme ça utiliser le même kernel sur deux boards différentes (mais de la même archi, quand même) en changeant juste le dtb.

Quant au ramdisk, je suppose que tu parles de l'initramfs (anciennement initrd). Bah ça c'est comme sur n'importe quelle distro d'aujourd'hui : ça contient les modules nécessaires au boot de ta carte. Pareil qu'avant, ça permet de mettre plein de drivers dedans pour plein de périphs différents, mais qui ne seront chargés qu'en fonction de leur utilisation.

Sinon, tu aurais pu aussi préciser ce qu'était le "avant" et "après" dans ta description, c'est toujours utile pour avoir un peu de contexte.

Franchement, t'as jamais dû utiliser d'iPhone toi. Essaye d'oublier tes préjugés à 2Fr, et essaye de voir ce que donne l'interface d'Apple objectivement (oui, essaye d'oublier tout le mal qu'il y a derrière ; là-dessus je suis d'accord).

ce n'est pas réellement possible d'avoir des donnée membres private/protected

Effectivement. Mais ces qualificatifs n'ont toujours été que des indications pour le programmeur : il y a toujours moyen de le contourner dans le langage. D'où le principe de python d'en faire une indication "visuelle" seulement : quand tu veux faire du "private", tu préfixes ta variable avec deux underscore. Pour du "protected", avec un underscore.

"as" est un mot-clé dans python depuis quelques temps déjà (au moins 2.4), c'est complètement con de l'utiliser comme nom de variable. À mon avis y'avait des warnings avant. OK, c'est pas tip top de passer de "warning" à "syntax error", mais voilà quoi, normalement on n'utilise pas des mots-clés comme nom de variable.

Je l'ai juste testé à la FNAC, et une des constatations que j'ai faite : plantage en moins de 5 minutes. Revu quelques jours plus tard : planté ou moment où je suis arrivé. Bref, pour l'instant, niveau soft, c'est pas ça.

Par contre le rasoir de sûreté m'irritait quand même plus qu'un bi-lame à tête jetable

Ah, je compte passer du deux lames jetables au rasoir de sûreté : ça irrite vraiment plus ? Vu que tu parles au passé, t'es passé à autre chose ? Ça m'inquiète un peu ...

Les lames Gilette de base coûtent 2 euros les 10 [...][soit] un coût récurrent un peu inférieur [aux Bic de base]

Je ne connais pas le prix des Bic, mais par rapport à un Gilette 2 lames, c'est plutôt largement moins cher : c'est facile 10€ les 10 ! Et je ne parle même pas des 3/4/5 lames ...

Je compte passer à un rasoir de sûreté, et vu le prix, ça me tente vraiment bien !