Je cite: "Par défaut le kernel d'Ubuntu est configuré pour la zone US. Or cette zone ne contient pas plusieurs canaux régulièrement utilisés en France (comme les canaux 12, 13).".
Wouoooo.... bon sang fallait le savoir. C'est pas con. Merci.
Lien: http://doc.ubuntu-fr.org/wifi#autorisation_du_canal

Télécharger un fichier par HTTP sous Windows sans IE, avec uniquement le système standard (via Timo)
EDIT: http://lehollandaisvolant.net/index.php?mode=links&id=20130806213652  :-)

Et oui... parfois un bon vieux FTP ou HTTP ça marche mieux que tous les bricolages soit-disant "plug and play" des gros éditeurs (AirPlay et autres).
Les technologies KISS/low-tech sont sûrement moins sexy, mais permettent de s'en sortir sans se prendre la tête.
Je ne compte plus le nombre de fois où j'ai pris un bon vieux FTP/HTTP parce que deux machines Windows de même version refusaient de voir leurs dossiers partagés par SMB.

Non non non... stop. Ça fait au moins le douzième chercheur qui pense avoir découvert un saint-graal capable de remplacer TCP/IP les doigts dans nez, les orteils dans les oreilles et un flamand rose sur la tête (non mais franchement, un flamand rose sur la tête !).
A chaque fois ça fait des merveilles en labo, et ça se casse la gueule dans la vraie vie (qu'on appelle "internet").
Je suis devenu extrêmement méfiant devant ce genre d'annonce.

Enfin une explication simple sur WSGI, qui est une excellente technologie de Python et ses librairies.

Ça peut toujours servir: netsh wlan export profile key=clear

Un outils pour couper la connexion TCP entre deux machines.

Un service en ligne pour tester votre connectivité IPv6 (via http://links.kevinvuilleumier.net/?lAybSg)

TOR est très bon pour masquer son trafic réseau: Il ressemble à du trafic HTTPS normal. Étant chiffrés (SSL), impossible d'inspecter le contenu des paquets. Pourtant, il existe un logiciel capable de détecter le trafic TOR en faisant des analyses statistiques: CapLoader (http://www.netresec.com/?page=CapLoader)

(via http://links.kevinvuilleumier.net/?4N-ddg)

Un client FTP/FXP freeware pour Windows (pour les allergiques à FileZilla)
http://www.wftpserver.com/download.htm#downfile2

Tiens, il existe une interface graphique pour la version Linux d'Hamachi (qui, je rappelle, a été racheté par LogMeIn).
http://www.haguichi.net/

Un client RDP/VNC/Citrix/SSH/Telnet unifié. Pratique.
http://www.mremoteng.org/home

mmm... l'idée n'est pas conne. En réseau, il y a de la perte de paquets, que ce soit purement des problèmes de routage IP, ou des problèmes liés au média (WiFi, etc.). C'est (entre autres) pour cela que TCP existe: il envoie une confirmation des paquets reçus, et permet la ré-émission des paquets perdus. Mais cela a un coût: demander les retransmissions, les attendre, être limité par la fenêtre TCP...   Alors voilà l'idée: Plutôt que redemander les paquets perdus, on calcul en permanence des codes genre Reed-Solomon qui sont transmis avec les données.
S'il manque un paquet, on le reconstruit à l'aide des codes correcteurs déjà reçu (à la manière de PAR2).

Pas con du tout. Avec ce principe, on pourrait (certains vont hurler) ré-inventer TCP à l'aide de paquets UDP: Transmettez les données en UDP plein pot (on évite la négo TCP et son fenêtrage) en entremêlant des paquets contenant des codes correcteurs. Les paquets UDP manquants ne sont pas redemandés, ils sont calculés à partir des codes correcteurs.
On pourrait même imaginer que le taux de paquets "code correcteurs" s'adapte automatiquement, ou alors prévoir juste l'envoi d'un paquet demandant l'augmentation de la proportion des paquets correcteurs.

Intéressant.

C'est assez similaire au protocole Avalanche de Microsoft, sauf que ça se situe plus bas dans les couches réseau.

(J'ai un article en préparation sur les codes correcteurs, et un exemple pratique avec PAR2. Je publierai ça un de ces jours.)

Intéressant.

ah tiens, pas mal: Un client pour naviguer sur les comptes FTP/SFTP/WebDav/AmazonS3/GoogleDrive/Azure/Rackspace. Pour Windows et Mac. Et c'est gratuit. (via Sirchamallow)

Je vais rappeler cette vieille astuce pour vous faire gagner du temps: Quand vous bloquez des sites avec le fichier hosts, ne mettez pas 127.0.0.1 mais 0.0.0.0.
En mettant 127.0.0.1, le navigateur essaiera de se connecter à cette adresse IP pour récupérer le contenu (qui fera, au bout d'un moment, un timeout). Donc un ralentissement des pages malgré tout.
En mettant 0.0.0.0, la connexion échoue immédiatement: Vos pages se chargeront plus vite.

EDIT: On peut parfaitement bloquer des sites avec le fichier HOSTS de Windows 8 : Il suffit de désactiver Windows Defender qui protège contre sa modification.

Exemples pratiques avec ZeroMQ (même si malgré le titre l'article n'a *RIEN* à voir avec les systèmes distribués).

Rappelons-le: Malgré son universalité et sa facilité d'utilisation pour la mise en place de VPN, on ne devrait plus utiliser PPTP. Beaucoup de VPN (dont IPredator, le VPN de PirateBay) l'utilisent encore.
Accessoirement, cet article vient de me faire découvrir de manière effrayante le cassage de mots de passe dans le cloud: Des services commerciaux de cassage de hashs, WPA2...: https://www.wpacracker.com/

EDIT: Article chez ArsTechnica: http://arstechnica.com/security/2012/07/broken-microsoft-sheme-exposes-traffic/
et article détaillé sur le blog: https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/

EDIT: Suite de la réflexion (et article en français): http://sebsauvage.net/links/?egPHNQ

ah... finalement ZeroMQ n'est peut-être pas si bien que ça: code devenu inmaintenable, communauté qui fuit, problèmes de locks...
(ZeroMQ est une surcouche aux sockets qui garantie l'arrivée des messages en vérifiant si le peer est dispo, en mettant les messages en queue, en retransmettant les messages échoués, etc. C'est le pendant opensource de MQSeries d'IBM.)

OH !  Je comprend le foirage de certaines appli et script que je faisais tourner sur un lecteur réseau: si vous faites un read() ou un read(x) avec x>64 Mo, l'OS va vous envoyer chier si vous travaillez sur un lecteur réseau. C'est une limitation de Windows.  Doh. Mémo: toujours faire tourner mes script en local, pas stockés sur un lecteur réseau.
Sous Python, vous aurez une jolie erreur "IOError: [Errno 22] Invalid argument" sur un appel à .read()

Hahaha ! Toujours aussi bons, Orange. Même avec la fibre, il y a Internet, et Internet bridé par Orange. Philippe a dû monter un tunnel vers une machine dédiée chez OVH pour pouvoir télécharger à plein régime. C'est lamentable d'avoir à en arriver là, non ?

EDIT: Article sur mon blog: http://sebsauvage.net/rhaa/index.php?2012/04/12/09/37/29-alors-cette-penurie-d-adresses-ipv4-on-en-est-ou-
Alors cette fameuse pénurie d'adresses IPv4 et l'écroulement annoncé d'internet, on en est où ?...  Ben pas bien loin, en fait: Non seulement internet ne s'est pas écroulé, mais il y a encore *plein* d'adresses IPv4. D'après vous, à qui a profité ces annonces apocalyptiques ? Aux vendeurs de solutions IPv6 et aux détenteurs de plages d'IPv4 (qui ont pu faire monter les prix).  Pffff...