__o a écrit 218 commentaires

Pour infos, jQuery c'est toujours du Javascript hein :)

Si tout ton PC rame parce qu'un processus part dans une boucle infinie, change de kernel.

Et ceux qui font des économies remboursent moins que ce qu'ils ont emprunté ? (c.f. les ronds vert sur la carte)

Le surcoût c'est quoi, c'est le montant des intérêts ? La différence par rapport à ce qui était prévu au départ ? Autre chose ?

Les extensions ont accès à absolument tout.

Y a-t-il une vérification avant la publication ?

Non

oups c'est ce que tu disais, désolé.

Dans ce cas, tu tombes sur les problèmes de cross-domain et ajax est à bannir

JSONP est une solution qui fonctionne très bien pour ça.

Qui utilise flex ? pour faire quoi ?

sites web en flash, là oui, ils sont clairement en déclin

Et c'est déjà énorme.

Youtube, dailymotion, deezer et après ?

Deezer n'utilise plus flash :)

Ça incrément seulement de 5 ici:

grep Pid /proc/self/status

sur une moyenne de quelques dizaines de secondes c'est à peu près constant, mais si tu le regarde au dizième de seconde près tu constatera que ça ne l'est pas.

Évidemment. Tout ce qui compte c'est si cette moyenne est supérieure à ce que le support de stockage peut absorber. Si elle l'est, le cache d'écriture se rempli.

Un serveur web fait beaucoup plus de lectures que d'écritures,

Oui. Je parlais surtout du serveur de base de données qui est derrière en fait. C'est très courant un serveur de base de données dont les I/O sont le goulot d'étranglement.

et s'il doit relire une donnée qu'il vient d'écrire peu de temps avant il y a un gros gain si celle-ci est encore en cache. (mais là j'ai plus en tête la cache RAM gérée par Linux

Tout à fait, je disais exactement ça quelques messages plus haut, pour le cache de lecture.

Tu pourras certainement désactiver le lancement de SSH comme tu le fais actuellement.

Avec un init classique l'utilisateur est bloqué devant la barre de progression du fsck, donc il attend que ça se termine.

Avec systemd le fsck se fait au moment où la partition est montée, c'est à dire au moment où l'utilisateur se log. Et à ce moment là à priori il ne vois pas la barre de progression, il ne sais pas qu'il y a un fsck en cours, il a seulement l'impression que login a freezé.

Donc ce cache ne sert qu'à lisser des piques d'I/O sur des machines peu utilisées ?

Si tu as un débit d'écriture constant au fil du temps enfin, il me semble que la plupart des machines ne sont pas utilisées sur ce principe.

Un serveur web (ou le serveur de base de données qui est derrière) qui fait plein de petites requêtes par seconde a un débit d'I/O à peu près constant.

Et sur ces machines, un cache d'écriture se remplis tellement rapidement que ça ne sert à rien.

[...] temps de réponse sont importants [...] des écritures puissent bloquer pendant une seconde

Sur un service où les temps de réponse sont importants, on écrit pas du code qui arrive à faire tellement d'I/O d'un coup qu'il bloque toutes les autres requêtes pendant une seconde, sur un serveur qui était pourtant sans aucune charge.

Intuitivement, ça a un intérêt très limité:

Quand on fait des écritures à une vitesse plus rapide que les disques ne peuvent écrire (ce qui est toujours le cas, sinon on a pas besoin de cache), le cache se rempli très vite (vu qu'il y a plus de données qui entrent dans le cache que de données qui en sortent).

Donc le cache est toujours saturé. Et lorsque le cache est saturé, pour écrire dans le cache il faut d'abord qu'une partie des données en cache soient réellement écrites sur le disque.

Et donc au bout de quelques secondes ou minutes d'utilisation, on obtient les mêmes performances qu'un contrôleur sans cache, non ?

optimiser la lecture en gardant les blocs les plus lus

il me semble que linux fait ça très bien déjà, et vu qu'il n'y a pas besoin que ce cache survive à un arrêt du système, on peut très bien laisser linux s'en occuper. D'autant plus que ça doit certainement être moins coûteux pour le système de lire une page de cache en mémoire que de demander une page au contrôleur.

Oui oui, c'est pour ça que j'ai précisé « sans autorisation du site web » :)

Donc pour Google cette page est accessible au public, et il n'y a pas de volonté de la part de Google de mettre à disposition du public des articles normalement payants.

Et comme le dit le commentaire au dessus, c'est depuis toujours un motif de blacklistage.

Ok, donc le problème c'est les liens profonds. Il a des solutions techniques évidentes pour empêcher ça, mais c'est totalement idiot.

Ton calcul est inexact, si Google ne peut plus faire un lien direct vers les articles, il ne peut plus faire de lien tout court. Donc c'est 0 impressions. Le lien profond n'est pas un manque à gagner, c'est que du bonus.

c’est la mise à disposition des articles mis en cache qui est remise en cause

<meta name="robots" content="noarchive">

Avec ça, Google ne met plus à disposition ce cache.

elle met à disposition du public des articles payants

Si Google a accès aux articles payants, le public aussi. Google n'a pas une porte magique pour accéder à des contenus payants sans autorisation du site web.

Quand on clique on arrive sur une page de lemonde.fr, si ils mettent pas de pub dessus, c'est leur choix non ? Ou alors je comprends pas, qu'est-ce qui fait que la pub est bypassée ?

la police des fans de google

Habituellement LinuxFR n'est pas le dernier à taper sur Google, pour des questions de vie privée par exemple. Il ne me semble pas que LinuxFR soit peuplé de Google fanboys.

Je me demande si les réactions auraient été aussi unanime si bong avait agit de la sorte

http://www.bing.com/search?q=site%3Awww.lesoir.be&go=&qs=n&sk=&form=QBRE&filt=all

Bing bloque les mêmes sites que Google.

Lis le jugement, la justice demande à google de retirer les images/liens/articles/etc des sites google.com et google.be; donc aussi bien news.google.com que le moteur de recherche.

C'est sur l'avant dernière page de
http://www.copiepresse.be/pdf/Copiepresse5mai2011.pdf .

Le serveur DNS avait explosé

Exemples:

"Naissance d'un gant"
https://twitter.com/#!/linuxfrorg/status/89310717022437376

"Petit tat de l'art"
https://twitter.com/#!/linuxfrorg/status/88917152622592000