@dominique http://www.atlantico.fr/decryptage/jeunes-peur-musique-classique-diffusion-musique-classique-parcs-publics-co là franchement on a touché le fond non ? Ou, dit autrement, c’est la guerre non ? Quel dégoût !
@dominique http://www.atlantico.fr/decryptage/jeunes-peur-musique-classique-diffusion-musique-classique-parcs-publics-co là franchement on a touché le fond non ? Ou, dit autrement, c’est la guerre non ? Quel dégoût !
Curieusement (ou pas), ce genre d’idée à la con n’émerge jamais seule quelque part : Jerusalem Residents Plan to Fight Muslim Prayer Call with Rock and Roll Music
http://www.algemeiner.com/2012/07/16/rock-and-roll-to-fight-muslim-prayer-in-jerusalem
Residents of the French Hill neighborhood in Jerusalem plan to combat Arab prayer-calls by blasting music from loudspeakers, in defiance of Arab religious conventions. According to Israeli newspaper Yediot Aharonot, Israelis plan to broadcast music from loudspeakers positioned toward a mosque in the Arab village Al Issawiya, located in Jerusalem on Mount Scopus near Hadassah Hospital.
RFC 6606 : Problem Statement and Requirements for 6LoWPAN Routing
Il y en a, des #RFC produits par le groupe de travail 6lowpan, qui a pour tâche de normaliser des protocoles pour les #LowPAN (Low-Power Wireless Personal Area Network), ces réseaux de toutes petites machines, limitées en puissance de calcul et en électricité (réseaux de capteurs industriels, par exemple). Parmi les questions soulevées par les LowPAN, le routage. Les liens radio #802.15.4 entre les machines ont une portée limitée et la communication entre deux machines queconques du LowPAN nécessite parfois une transission par un ou plusieurs routeurs intermédiaires. Les normes des couches basses, comme IEEE 802.15.4 ne spécifient pas de mécanisme pour gérer ce routage. Ce RFC 6606 est le cahier des charges pour les protocoles de routage du LowPAN, protocoles qui seront établis par d’autres groupes comme Roll, qui travaille sur un problème plus général que celui des seuls LowPAN et a normalisé le protocole RPL dans le RFC 6550. Notez qu’l y a eu d’autres RFC proches comme le RFC 5826 qui se focalise sur le cas particulier de la domotique, ou le RFC 5673, pour les réseaux industriels.
RFC 6550 : RPL : IPv6 Routing Protocol for Low power and Lossy Networks
Il y a beaucoup d’intérêt en ce moment pour un (largement mythique) « #Internet_des_objets » qui mèle des fantasmes domotiques éculés (le réfrigérateur qui commande tout seul des bières à Carrefour via l’Internet, lorsqu’il est vide), l’arrivée massive d’ordinateurs qui ne sont pas considérés comme des ordinateurs (smartphones, tablettes, télévisions connectées), la connexion à des réseaux TCP/IP d’équipements très modestes, et la diffusion de plus en plus large d’étiquettes RFID. Pour les ordinateurs (un smartphone, bien plus puissant que l’ordinateur qu’embarquait les vaisseaux Apollo, mérite tout à fait ce titre), un des enjeux de l’Internet des objets est le routage des paquets IP. Ces « objets » ont des ressources électriques limitées, et sont souvent connectés par des liens radio de qualité médiocre. Les protocoles de routage traditionnels ne sont pas très adaptés à cette situation. Le groupe de travail ROLL de l’IETF travaille sur ce problème et vient de produire son protocole « officiel », #RPL (Routing Protocol for LLNs où un LLN est un Low power and Lossy Network, un réseau où mêmes les routeurs ont peu de courant et où pas mal de paquets se perdent en route). Le groupe ROLL a déjà produit plusieurs #RFC détaillant les demandes de ces LLNs : RFC 5867, RFC 5826, RFC 5673 et RFC 5548. Il a également normalisé l’algorithme de distribution utilisé par RPL, Trickle (RFC 6206).
RFC 6206 : The Trickle Algorithm
Dans le cadre des travaux sur l’#Internet_des_objets, le groupe de travail ROLL de l’IETF s’occupe de définir des mécanismes de #routage pour des réseaux d’engins aux capacités limitées, et connectés par des liens radio à faible portée et souvent brouillés. (Par exemple, cela peut décrire la situation de capteurs dans une usine.) Une brique de base pour beaucoup de protocoles utilisés dans ce contexte est un algorithme pour coordonner un état entre toutes les machines (cet état pouvant être par exemple la tale de routage, mais aussi une configuration commune). #Trickle est l’algorithme utilisé et ce RFC est sa première normalisation.