At 10:30 p.m., 29 October 1969, the first ARPANET message was sent from the UCLA's room 3240 (by Charley Kline) to the Stanford Research Institute (SRI, received by Bill Duvall). Based on packet switching and dynamic resource allocation, the sharing of information digitally from this first node of ARPANET launched the Internet revolution.

> Perhaps three people will read this essay, including my parents.
Well, I'm happy to be the 4th ;-)

> (...) the most reliable way to get better results is to just produce more crap.
Sounds weird out of context, but true (I think ;-)

> Smartphones, I’ve decided, are not evil. This entire essay was composed on an iPhone. What’s evil is passive consumption, in all its forms.

This made History ;-)

Intéressant (et un peu choquant aussi), même si certains chiffres me font un peu tiquer : 24Wh pour un email avec une pièce jointe, ça me semble énorme (est-ce que ça inclut la consommation de l'ordinateur sur lequel on l'écrit et celle de l'appareil sur lequel on le lit, ou simplement la consommation de tous les engins entre les 2 ?)

Concernant la production de l'électricité nécessaire à l'alimentation des datacenters, c'est encore le bon vieux débat "énergies fossiles vs nucléaire vs énergies renouvelables". On a déjà (presque) tout dit sur la question sans être tellement plus avancés... (donc j'essaie même pas).

Le coup du "Google a ouvert un Data Center écologique en Finlande : il compte le refroidir naturellement grâce à l’énergie hydraulique et aux températures glaciales qui sévissent dans le pays." me fait rire jaune. Installer un datacenter dans un pays froid n'est PAS écologique : au final, il y a toujours la même quantité d'énergie thermique transmise des serveurs vers l'atmosphère, sauf que là, Google ne paie pas la clim'. C'est limite du foutage de gueule, je dirais, de considérer ça comme "écologique" !!!

La solution suggérée en fin d'article : le développement à grande échelle des énergies renouvelables + la "smart grid" est un peu le serpent qui se mord la queue : il faudra d'autres serveurs pour que tous les équipements "intelligents" s'échangent des infos pour optimiser la production et la consommation d'électricité. (mais si c'est bien fait, ça peut marcher, c'est vrai ;-)

"et enfin les véhicules devenus électriques seront à même d’acheter ou de vendre de l’électricité sur ce réseau à n’importe qui."
Alors celle-ci, on nous la ressort tout le temps : c'est bien joli les voitures électriques, mais d'où vient l'énergie pour les recharger ? Ce n'est pas une question de progrès technique ni même de kilomètres carrés de panneaux solaires ou de champs d'éoliennes, mais une bête application du principe de conservation de l'énergie : si on arrivait à récupérer 100% de la force du vent, des marées, des cours d'eau, 100% de la lumière solaire (et 100% de toutes les autres énergies renouvelables que j'oublie), en aurait-on assez pour se passer des énergies "traditionnelles" (fossile, nucléaire) ?

Pour terminer : y'a 20 ans, une page web devait peser moins de 100KB, tous ceux qui "avaient" un site web, crachaient du HTML (ou utilisaient frontpage) et on avait nos bien vieux modems 56K (voire moins).
Aujourd'hui, la moindre page web fait 5MB, contient 3 ou 4 bannières de pub (dont une vidéo en autoplay) et les dévs web (qu'on presse comme des citrons) font au plus vite en réutilisant des libs JS toutes prêtes, quitte à alourdir les pages de quelques centaines de KB supplémentaires pour une animation / un fondu / une transition / un effet "trop stylé". Là aussi, on voit bien que nous sommes dans une société de (sur)consommation. De bande passante, en l'occurrence. Donc des plus gros tuyaux, des plus gros disques durs / serveurs / datacenters...

(via : https://shaarli.mydjey.eu/?OTfgSg)

Quite a good summary ;-)

Tout est dans le titre (et un peu dans les commentaires aussi ;-)

(via : http://jdxlabs.com/links/?qZ7xRQ)

A deep dive into Internet infrastructure, plus a rare visit to a subsea cable landing site.

Un article récent de Zythom (http://zythom.blogspot.fr/2016/03/les-russes-attaquent.html) évoquait le "null routing", le présentant comme une solution facile et efficace pour filtrer les connexions entrantes. Il suffit de :

route add -host addrIP reject

et le tour est joué !


Le sujet m'a intrigué (ce qui est trop beau pour être vrai mérite d'être remis en question, analysé, décortiqué), et j'ai lu 2-3 trucs sur la question. Voici donc quelques notes en vrac en attendant que tout cela devienne clair.


- 'man route', option 'reject' : install a blocking route, which will force a route lookup to fail. This is for example used to mask out networks before using the default route. This is NOT for firewalling.
NB : this option sends "Network is unreachable" message back to client.


- http://www.cyberciti.biz/tips/how-do-i-drop-or-block-attackers-ip-with-null-routes.html : seen in the comments :

route add 65.21.34.4 gw 127.0.0.1 lo

When packet is received from 65.21.34.4, it always gets connected to the host (if you didn't drop the packet with iptables) it is processed and when it has to send the answer to 65.21.34.4 with the needed data, the static route tells to forward this packet to the loopback interface, so the packet never comes back to the 65.21.34.4 (bad attacker host)

Other comment : I don’t see the point of this, unless you don’t have iptables – a stretch. And the truth is, it is not significantly simpler than iptables, at what it does.


- https://en.wikipedia.org/wiki/Null_route
(pro) Null routing has an advantage over classic firewalls since it is available on every potential network router (including all modern operating systems), and adds virtually no performance impact. (...) null routing can often sustain higher throughput than conventional firewalls.
(con) Routing typically only works on the Internet Protocol layer and is very limited in packet classification. It is bound to be stateless due to the nature of IP routers. Typically, classification is limited to the destination IP address prefix, source IP address and incoming network interface.

>La rétention des données de connexion passerait d’un an à deux ans

AMHA, durcir certaines contraintes techniques est une fausse bonne idée, qui revient à se tirer une balle dans le pied à long terme. Pour ceux qui s'en rappellent, les lois DADVSI en leur temps, puis Hadopi, ont tué (ou fortement réduit) l'usage de logiciels tels que Amule/BitTorrent qui échangeaient des données -certes illégales- mais au moins en clair.
Pour tous ceux qui s'inquiétaient de la sécurité intérieure et qui ouvraient bien grand leurs oreilles électroniques, il était alors facile de discriminer un contenu "intéressant" du "bruit de fond" des Internets (si ça se trouve, le simple fait que le transfert ne soit pas en clair devait déjà être un critère... Bon, dans le tas, y'avait aussi des achats en ligne, mais en volume, ça permettait sûrement un 1er tri). Puis des lois sont passées, on a dit "Télécharger = PAS BIEN, il faut ACHETER des DVD !" et nos gouvernants se sont félicités de cette avancée. Oui mais voilà : quelques années plus tard, le direct download en HTTPS permet à l'internaute moyen d'engendrer des giga-octets de trafic chiffré en 3 clics. Si j'étais chargé d'"écouter" Internet dans le cadre d'une activité de renseignement, je pense que ça me ferait bien râler !

Pour les données de connexion, puisqu'on ne peut pas empêcher qu'elles soient stockées/conservées/analysées, on peut être bête et méchant et causer du trafic automatiquement histoire de faire une PLUS GROSSE meule de foin dans laquelle ce sera nettement plus amusant de chercher (tout en faisant exploser le coût du stockage). Sans aller très loin, à coup de mots pris dans un dictionnaire + requête google + visite des 3 1ers résultats (tout en wget vers /dev/null), ça doit pouvoir se scripter assez facilement et générer un nombre de "données de connexion" assez délirant...