Bruno Michel a écrit 3285 commentaires

C'était effectivement le cas il y a quelques années, mais depuis les sites web ont évolués. Globalement, ils font appel à de plus en plus de ressources séparées (feuilles de styles, beaucoup de javascript, images, polices, etc.), or multiplier les requêtes HTTP ralentit le temps de chargement des pages.

Pire, l'augmentation de la bande passante a un effet quasi négligeable sur le temps de chargement (pour les gens qui ont au moins une connexion ADSL). En gros, passer de 10 Mbits à 20 Mbits ne va pas aider à afficher plus rapidement les pages web car le problème est principalement une question de latence (résolution DNS, ouverture de sessions TCP, éventuellement SSL, attendre d'avoir parsé le HTML pour savoir quelles ressources télécharger, etc.). Au final, malgré les progrès techniques, les pages web s'affichent moins rapidement aujourd'hui qu'il y a 2 ou 3 ans en moyenne.

Et cela ne devrait pas aller en s'améliorant. Les sites web utilisent de plus en plus de ressources externes (trucs de facebook, google analytics, embed youtube, boutons "share this", commentaires gérés par des services externes comme disqus, etc.), ce qui multiplie les risques qu'une page se charge lentement.

D'un autre coté, le temps de chargement des pages est de plus en plus mis en avant : Amazon a publié des études qui montrent qu'un temps de chargement un peu plus long (genre 100ms de plus) provoquent des chutes vertigineuses dans les ventes (10 à 30%), Google tient compte du temps de chargement des pages pour son indexation.

On voit donc se généraliser des techniques pour optimiser le temps de chargement des pages : minification des CSS et JS, regrouper plusieurs fichiers dans un seul, le retour des sprites CSS, le préchargement de ressources, etc. La promesse du mod apache de Google est de faire ça automagiquement , à grande échelle, sur des sites existants pour lesquels ces opérations ne seraient pas faites autrement.

Ça ne me semble pas une bonne idée du tout que de vouloir mettre cet identifiant de session dans une URL. L'URL est quand même une donnée destinée à être publique.

Par exemple, l'utilisateur ne doit pas oublié d'enlever cet identifiant quand il partage une URL avec d'autres utilisateurs. Utiliser HTTPS n'aide en rien dans ce cas.

Plus vicieux, l'URL peut se retrouver dans les fichiers de logs, que ce soient ceux de proxys ou d'autres serveurs via le mécanisme du Referer. Et là, HTTPS a une légère influence (la RFC dit : « Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol »).

Il est possible d'utiliser IMAPS (IMAP over SSL), mais ce n'est malheureusement pas supporté par beaucoup de serveurs.

Je n'ai pas la même interprétation que toi. De ce que j'en ai compris, une application qui demande 20Mo de mémoire mais qui n'en utilise que 2 sur une machine qui a 2Go de mémoire + swap aura un score de 1 (2 divisé par 2000). Avant le 2.6.36, cette même application aurait eu beaucoup plus de chances se faire tuer car son score aurait été fonction des 20Mo demandés et non pas des 2Mo réellement utilisés.

Je dirais http://tools.ietf.org/html/rfc5737 et http://tools.ietf.org/html/rfc3849

Donc, on est bien d'accord que la définition est biaisée, car l'adresse IP ne permet pas d'identifier de manière unique un ordinateur (Mac, PC, Nintendo DS) dans le sens auquel l'entend le grand public.

C'est quoi ta définition de « connecté à Internet » ?

Pour moi, quand un ordinateur peut échanger des informations avec un autre ordinateur qui est connecté au net, alors il est aussi connecté à Internet.

Je ne suis pas d'accord. Pour le grand public, un ordinateur, c'est une tour ou un ordinateur portable, mais sûrement pas une box. Et on ne peut absolument pas identifier l'ordinateur, ie le poste, à partir d'une adresse IP mais seulement la box.

Dans le cadre d'Hadopi, cela a toute son importance, ça va dire que s'il quelqu'un a réussi à utiliser ton réseau wifi pour télécharger illégalement, l'adresse IP sera la tienne et pas celle de la personne qui a vraiment fait le téléchargement.

À la limite, je veux bien accepter cette définition pour le grand public si on remplace ordinateur par équipement réseau.

> Tu as déjà essayé de monter un serveur derrière une *box ?

Oui, ça se fait bien (redirection de port ou routage par défaut). Il y a quelque chose de particulier à remarquer ?

Et pour les adresses IP multicast, tu explique cela comment ?

> Et dire que ce thème est marqué "obsolète" sur la page des styles. :)

Rah, c'est moi qui me suis raté. Je corrige.

> Utilisent-ils l'adresse mail attribuée par le FAI ou celle qu'on renseigne sur la déclaration d'impôts ?

L'adresse mail fournie par le FAI.

> C'est moi ou "." ça n'a rien à voir avec "^$" ? Je dirais même que c'est l'inverse en quoi l'un devrait être plus rapide que l'autre ?

Oui, "." est précisément l'inverse de "^$", d'où la comparaison entre grep . et grep -v "^$" (le -v sert justement à inverser la sélection) qui font du coup la même chose : récupérer les lignes non vides.

> Ça veut dire qu'il vaut mieux utiliser grep -v '.' que grep '^$' ?

Le premier est probablement plus rapide que le deuxième, mais j'imagine que la différence dans la pratique va être négligeable à moins d'avoir un fichier dont on veut récupérer beaucoup de lignes vides, ce qui ne doit pas arriver souvent.

L'audit n'est pas si simple à passer. Une entrée dans le bugtracker de mozilla avait été ouverte pour l'inclusion de CaCert, puis refermée à la demande de l'auditeur de CaCert : https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158

En gros, CaCert ne se considérait pas prête pour l'inclusion et voulait faire une grosse liste de tâches avant de redemander son inclusion. Je sais que depuis il s'est passé pas mal de temps et que la liste de tâches a avancé, mais je ne saurais pas dire quel est son degré d'avancement.

Le certificat de LinuxFr.org n'est pas auto-signé, il est signé par CaCert.org. Les raisons de ce choix ont déjà été expliquées plusieurs fois, par exemple sur http://linuxfr.org/comments/1044250,1.html

On a une entrée dans le suivi à ce sujet : http://linuxfr.org/tracker/1157.html mais ça ne devrait pas arriver de suite (question de priorité).

Un de mes collègues a regardé le code de diaspora, et il semblerait que celui-ci ne soit pas si acentré qu'il en a l'air. En particulier, chaque utilisateur serait identifié par un guid sur http://joindiaspora.com/. Les détails sont sur http://dev.af83.com/diso/diaspora-seems-poorly-thought-out/2(...) .

> Ca prouve rien. C'est ce journal qu'à réveiller le commiteur ?

Non, le commit en question date d'avant le journal.

> c'est des commits de quelques lignes à chaque fois. Alors c'est déjà fini, et c'est du fine-tuning là ?

C'est surtout que j'étais en vacances une partie du mois d'août, et à mon retour, j'ai eu du mal à m'y remettre. Mais ça va repartir :-p

Le pub/sub de redis est pratique quand on utilise déjà redis pour d'autres choses, mais je ne suis pas sûr qu'il convienne bien dans ton cas. Je te conseille de regarder plutôt du coté de 0mq [http://www.zeromq.com/] ou de RabbitMQ [http://www.rabbitmq.com/].

Le compte que tu avais trouvé sur twitter n'était pas un compte officiel. On s'est rendu compte justement lors de la panne qu'on devait avoir une présence officielle sur twitter et identi.ca. Les deux comptes sont donc récents et ont été créés en même temps.

> Ainsi, il est maintenant possible de suivre Toolinux sur Twitter ou Facebook

Il est possible de suivre LinuxFr.org sur twitter [https://twitter.com/linuxfrorg] et identi.ca [http://identi.ca/linuxfrorg]. Pour facebook, nous refusons par principe.

> Toolinux vient de subir un lifting complet pour être plus aux normes avec l'existant.

Heu, on ne doit pas avoir les mêmes normes. On ne peut toujours pas laisser de commentaires, même avec un service comme disqus. On en peut pas, non plus, proposer d'évolutions (que ce soit un suivi comme sur LinuxFr.org ou un outil en ligne à la uservoice).

Par contre, ils utilisent google analytics et google ad words, mais est-ce vraiment une avancée ?

> Toolinux est le site d'information francophone leader sur les technologies libres.

Non, faut pas abuser, ça c'est LinuxFr.org. D'après Alexa.com, on fait 5 à 10 fois plus de trafic que toolinux. Et nous, nos articles sont spécialement écrits pour LinuxFr.org, ce ne sont pas des repompes d'ailleurs.

> Linuxfr va t-elle réagir à cette offensive de charme de Toolinux ?

On se demandait si nous allions pas mettre des goatse.cx dans les flux RSS (juste pour Toolinux), vu qu'ils semblent sans servir sans avoir eu la courtoisie de nous l'indiquer (et encore moins de nous demander la permission).

> Est-ce que Twitter, Facebook et autres outils sociaux vont être intégrés pleinement dans l'interface ?

Pour facebook, la réponse est clairement non. Pour twitter, identi.ca ou des réseaux sociaux libres, c'est à voir (il n'y a pas vraiment de décision dans un sens ou l'autre).

> Personnellement, je fait cela via le fichier preferences d'apt où j'ajoute chaque paquet du backport. C'est pas très souple mais cela marche !

Aptitude propose également une option -t pour ça. Par exemple :
aptitude -t lenny-backports install nginx

Effectivement, au temps pour moi.

> A cause de l'absence de gestion de la persistance ?

Surtout parce que Redis est encore un produit assez jeune et que la réplication vient juste d'apparaître dans la version 2.0.

> Pour aller plus loin, est-ce qu'il existe une base no-sql qui garantie l'atomicité des mises à jour ?

Quasiment toutes les bases de données NoSQL garantissent l'atomicité, mais j'ai l'impression que ce tu recherches est la durabilité (en gros, la capacité de résister aux coupures de courant). Et là, les bases de données NoSQL ont des approches très différentes. Certaines garantissent la durabilité et d'autres non.

Un cas intéressant est celui de MongoDB. Par défaut, il ne garantit pas la durabilité. En pratique, c'est rarement un problème. Si tu as un seul serveur, ton plus gros risque n'est pas les pannes de courant mais les disques durs qui lâchent. Et là, durabilité ou pas, ta seule protection est d'avoir des sauvegardes régulières. Et si perdre des données n'est pas acceptable, alors il faut passer avoir plusieurs serveurs, et autant que possible dans plusieurs datacenters.