Désolé pour cette nouvelle qui pourrait etre une rumeur mais qui reste néanmoins logique et explique certains disfonctionnements
C'est un peu long mais ça en vaut vraiment la peine
GOOGLE IS BROKEN (se comporte comme s'il a un problème Y2K+3)
Pendant les 30 derniers jours, Google a fait des choses étranges. Aucun administrateur de site web qui suit Google ne niera étroitement cela. Il n'y a aucune explication de Google sauf quelques allusions vagues de "GoogleGuy", une affiche anonyme à webmasterworld.com, que le propriétaire de forum dit est de Google. Ces allusions prétendent que de nouveaux algorithmes sont mis Dans la place et que cela prendra un couple de mois.
Une autre explication possible, entièrement spéculative, est tout à fait intrigante et adapte les faits mieux que les affirmations vagues de GoogleGuy d'un changement d'algorithme. Cette explication a été obliquement niée par GoogleGuy, à lequel le point le pro Google propriétaire de forum, Brett Tabke, a déplacé le fil de la liste active. Le jour suivant ce fil a été fermé contre les nouveaux envois par la poste. Puisque l'on a su Que GoogleGuy a fait des démentis forts sur d'autres questions, cela s'élève à un nondémenti.
Nous appellerons cette explication intrigante le "Y2K+3 le problème." Il est d'autant plus intrigant parce que M. Tabke, un programmeur capable, a fait un envoi par la poste de fait d'induire en erreur dans le sens où l'addition d'un autre octet à la page Web ID le numéro(nombre) pour fixer un entier déborde le problème était "le jeu(pièce) de l'enfant," et a appelé le fil "faux". Le comportement de GoogleGuy et son copain M. Tabke ressemble à une opération de camouflage. On espère que cette page de résumé de Montre de Google encouragera plus de discussion de ce que se passe à Google, même si ne feront pas(seront) webmasterworld.com
D'abord, une explication de ce qu'est différent à Google pendant les 30 derniers jours. Ce tri(sorte) de comportement est entièrement sans précédent en 2.5 ans nous avons suivi Google :
1. Il y avait quelques résultats étranges a observé quand la mise à jour précédente a donné un coup de pied dans le 11 avril, mais les administrateurs de site web sont devenus universellement concernés en Mai, 2003. Il a pris environ deux semaines pour le Peut mettre à jour pour se propager aux neuf centres de données. Normalement il prend autour de cinq jours.
2. Les données en le mai ont montré la moitié du numéro(nombre) de backlinks que les administrateurs de site web ont été habitués à l'observation sur leurs sites.
3. Les données en le mai étaient d'une mise à jour précédente en février ou mars et pas de l'habituel profond rampent qui est arrivé dans la mi-avril. Il était comme si l'avril profondément rampe avaient été rejeté. GoogleGuy a essentiellement confirmé que c'était le cas. Les pages qui avaient été créées depuis février ou mars étaient, aussi souvent que pas, le manque.
4. Lentement, le freshbot a commencé à ajouter des pages plus récentes une fois des données en le mai arrangé. Mais comme est typique avec des données freshbot, ces pages ont persisté dans l'index pendant deux ou trois jours et ont ensuite abandonné l'index. Alors ils surgiraient de nouveau quelques jours plus tard. Cet effet d'yo-yo a obtenu l'attention de beaucoup d'administrateurs de site web qui n'étaient pas habitués à ce tri(sorte) d'instabilité. Freshbot manipule normalement des pages fraîches cette voie, mais tout à coup, la définition "de frais" couvert d'un laps de temps de trois mois. D'habitude le freshbot a un effet dramatique(spectaculaire) seulement aux pages qui sont nouveaux puisque le dernier profond rampent.
5. Le PageRank de ces pages "fraîches" est indéterminé. Il prend un profond rampent plus plusieurs jours de calcul pour calculer le PageRank pour le tissu entier. Sans l'avril profondément rampent des données, le PageRanks qui a apparu étaient de février ou mars. N'importe quelles pages "fraîches" n'ont depuis lors montré aucun PageRank du tout. Normalement la barre d'outils rapprocherait le PageRank pour des pages fraîches, basées sur le PageRank de la page d'accueil, mais il a arrêté de faire cela aussi. Tout il a montré était une barre(bar) tout-blanche ou grise. Cela a aussi attiré beaucoup d'attention d'administrateurs de site web. Plus de rampement le freshbot a fait, en particulier sur des pages d'accueil pour des sites dynamiques comme blogs, plus d'administrateurs de site web ont remarqué que leur PageRank ne montrait plus sur la barre d'outils. Il est toujours peu clair si PageRank réel (par opposition à ce que les expositions de barre d'outils) sont aussi indéterminées. La seule façon de juger c'est par les classements pour des mots-clés choisis. Quelques administrateurs de site web ont annoncé des fluctuations massives dans des classements, suggérant que le composant PageRank de l'algorithme se classant ait été en effet cassé(violé). C'était en plus du fait que les pages passeraient voir et de l'index.
6. Bot profond n'a pas apparu depuis la fin d'avril. C'est sans précédent pour bot profond de Google pour être AWOL pour course(direction) de six semaines.
La théorie Y2K+3
Spéculons. La plupart du logiciel fondamental de Google a été écrit dans 1998-2000. Il a été écrit dans C et C ++ pour courir sous Linux. À partir de juillet 2000, Google revendiquait un milliard de pages Web indexées. À novembre 2002, ils revendiquaient 3 milliards. À ce taux d'augmentation, ils seraient maintenant à 3.5 milliards, bien que le compte n'ait pas changé sur leur page d'accueil depuis novembre. Si vous cherchez le mot "@" le vous obtenez un compte de 3.76 milliards. Il est peu clair quel rôle d'autres langues auraient, s'il en est tels dans la production de ce compte. Peut-être chaque langue le fait être le propre lexique et c'est la propre page Web IDs. Mais n'importe quelle voie que vous le coupez, nous s'approche de 4 milliards très bientôt, au moins pour l'Anglais. Avec quelques numéros(nombres) vraisemblablement mis de côté pour le freshbot, il apparaîtrait qu'ils s'écoulent(sortent en courant) la page Web disponible IDs.
Si vous employez un numéro(nombre) d'ID pour identifier chaque nouvelle page sur le tissu, il y a un problème une fois que vous arrivez à 4.2 milliards. Numérote plus haut que cela exigent plus de puissance de traitement et le codage différent. Notre spéculation fait trois suppositions principales : a) Google emploie des fonctions standard pour la langue C dans leur programmation fondamentale; b) quand les programmes de Google ont été d'abord développés quatre ou il y a plus ans, ID unique ont été exigés pour chaque page Web; et c) cela a semblé raisonnable et efficace à ce temps-là pour employer un long entier non signé dans ANSI C. Dans Linux, cette variable est quatre octets de long et a un maximum de 4.2 milliards avant qu'il ne se retourne au zéro. Le suivant intensifient dans des variables numériques sous Linux exige des fonctions différentes standard dans ANSI C et plus de cycles d'UC pour le traitement. Quand les programmes fondamentaux ont été développés pour Google il y a plusieurs ans, il est raisonnable de supposer que l'on n'a pas vu les 4.2 milliards de limite supérieure comme un problème potentiel.
Il est aussi possible que le freshbot, qui a commencé le travail en août 2001, a été assigné son propre bloc de numéros(nombres) d'ID inutilisés de l'association(bassin) de 4.2 milliards. Cela tiendrait compte de l'intégration plus facile des données freshbot avec le profond rampent les données, mais suggéreraient aussi une certaine quantité(somme) d'inefficacité dans l'utilisation de numéros(nombres) disponibles. En effet, freshbot se comporte comme s'il peut seulement tenir un certain numéro(nombre) de pages totales, auxquelles le point il laisse tomber la page la plus vieille dans sa file d'attente de circulaire(tournoi) et le recopie avec une page plus récente d'un site différent. Cette habitude particulière pourrait être un autre symptôme de l'association(bassin) limitée de numéros(nombres) d'ID disponibles.
De n'importe quelle voie vous le coupez, si vous supposez que chaque page Web unique a besoin d'un numéro(nombre) des 4.2 milliards d'association(bassin) avant qu'il ne puisse être inclus dans l'index de Google, alors ou bien Google a des problèmes tout de suite, ou bien il prévoit des problèmes dans le proche avenir et commence à réviser les parties de leur système. Cela pourrait expliquer le comportement récent de Google.
Malgré l'avis de Brett Tabke, ce n'est pas le jeu(pièce) de l'enfant pour ajouter un octet et le faire un entier à cinq octets au lieu d'un entier à quatre octets. L'utilisation d'un octet supplémentaire signifie essentiellement que vous employez un caractère non signé comme un multiplicateur pour 4.2 milliards et ajoutez que sur l'entier pour obtenir votre résultat final. Si l'entier est A et le multiplicateur est B, le nouvel entier est un + (B * 4.2 milliards). Si B est zéro, donc vous obtenez A. Si B est un, vous obtenez des valeurs de 4.2 à 8.4. C'est que vous avez besoin d'une variable de multiplicateur supplémentaire et les lignes supplémentaires de code pour la conversion. (Vous pourriez employer un numéro(nombre) à huit octets dans Linux, mais cela pourrait être moins efficace de point de vue quantitative et emploie évidemment plus d'octets que vous le besoin.) Il n'y a aucune fonction standard dans la programmation des langues qui manipulent des entiers à cinq octets.
Pour quelque chose aussi de base qu'une page Web ID le numéro(nombre), cela implique une révision massive du logiciel de Google. En attendant, vous avez 15,000 Linux des boîtes pour mettre à niveau. Chaque boîte Linux à Google dirige censément un jeu standard de logiciel, pour qu'il puisse être échangé avec d'autres boîtes une fois que les données sont faites un double. Il est sûr de supposer que la page Web ID le numéro(nombre) est omniprésente sur toutes ces boîtes. La mise à niveau doit être faite dans des phases, autrement tout Google va en mode autonome pour peu de temps. La dégradation d'exécution(performance) est tolérable, donnée les circonstances, mais partant - la ligne signifierait une perte instantanée de part de marché. Les rajustements dans la capacité de données pour les index divers doivent être faits aussi, en raison de l'octet supplémentaire par la page Web ID.
Comme nous avons exposé au commencement de cette page, tous c'est spéculatif. Puisque Google ne nous dira pas ce qui se passe, nous sommes forcés d'encourager la spéculation sauvage dans l'espoir que Google le verra comme dans leurs intérêts pour être plus prochain de ce qu'ils sont jusqu'à.
Google croit qu'il n'est aucun de notre affaire. Mais ils sont faux. C'est notre affaire. Nous n'avons pas demandé à Google de devenir le courtier mondial de l'information; il est juste arrivé cette voie.
C'est un peu long mais ça en vaut vraiment la peine
GOOGLE IS BROKEN (se comporte comme s'il a un problème Y2K+3)
Pendant les 30 derniers jours, Google a fait des choses étranges. Aucun administrateur de site web qui suit Google ne niera étroitement cela. Il n'y a aucune explication de Google sauf quelques allusions vagues de "GoogleGuy", une affiche anonyme à webmasterworld.com, que le propriétaire de forum dit est de Google. Ces allusions prétendent que de nouveaux algorithmes sont mis Dans la place et que cela prendra un couple de mois.
Une autre explication possible, entièrement spéculative, est tout à fait intrigante et adapte les faits mieux que les affirmations vagues de GoogleGuy d'un changement d'algorithme. Cette explication a été obliquement niée par GoogleGuy, à lequel le point le pro Google propriétaire de forum, Brett Tabke, a déplacé le fil de la liste active. Le jour suivant ce fil a été fermé contre les nouveaux envois par la poste. Puisque l'on a su Que GoogleGuy a fait des démentis forts sur d'autres questions, cela s'élève à un nondémenti.
Nous appellerons cette explication intrigante le "Y2K+3 le problème." Il est d'autant plus intrigant parce que M. Tabke, un programmeur capable, a fait un envoi par la poste de fait d'induire en erreur dans le sens où l'addition d'un autre octet à la page Web ID le numéro(nombre) pour fixer un entier déborde le problème était "le jeu(pièce) de l'enfant," et a appelé le fil "faux". Le comportement de GoogleGuy et son copain M. Tabke ressemble à une opération de camouflage. On espère que cette page de résumé de Montre de Google encouragera plus de discussion de ce que se passe à Google, même si ne feront pas(seront) webmasterworld.com
D'abord, une explication de ce qu'est différent à Google pendant les 30 derniers jours. Ce tri(sorte) de comportement est entièrement sans précédent en 2.5 ans nous avons suivi Google :
1. Il y avait quelques résultats étranges a observé quand la mise à jour précédente a donné un coup de pied dans le 11 avril, mais les administrateurs de site web sont devenus universellement concernés en Mai, 2003. Il a pris environ deux semaines pour le Peut mettre à jour pour se propager aux neuf centres de données. Normalement il prend autour de cinq jours.
2. Les données en le mai ont montré la moitié du numéro(nombre) de backlinks que les administrateurs de site web ont été habitués à l'observation sur leurs sites.
3. Les données en le mai étaient d'une mise à jour précédente en février ou mars et pas de l'habituel profond rampent qui est arrivé dans la mi-avril. Il était comme si l'avril profondément rampe avaient été rejeté. GoogleGuy a essentiellement confirmé que c'était le cas. Les pages qui avaient été créées depuis février ou mars étaient, aussi souvent que pas, le manque.
4. Lentement, le freshbot a commencé à ajouter des pages plus récentes une fois des données en le mai arrangé. Mais comme est typique avec des données freshbot, ces pages ont persisté dans l'index pendant deux ou trois jours et ont ensuite abandonné l'index. Alors ils surgiraient de nouveau quelques jours plus tard. Cet effet d'yo-yo a obtenu l'attention de beaucoup d'administrateurs de site web qui n'étaient pas habitués à ce tri(sorte) d'instabilité. Freshbot manipule normalement des pages fraîches cette voie, mais tout à coup, la définition "de frais" couvert d'un laps de temps de trois mois. D'habitude le freshbot a un effet dramatique(spectaculaire) seulement aux pages qui sont nouveaux puisque le dernier profond rampent.
5. Le PageRank de ces pages "fraîches" est indéterminé. Il prend un profond rampent plus plusieurs jours de calcul pour calculer le PageRank pour le tissu entier. Sans l'avril profondément rampent des données, le PageRanks qui a apparu étaient de février ou mars. N'importe quelles pages "fraîches" n'ont depuis lors montré aucun PageRank du tout. Normalement la barre d'outils rapprocherait le PageRank pour des pages fraîches, basées sur le PageRank de la page d'accueil, mais il a arrêté de faire cela aussi. Tout il a montré était une barre(bar) tout-blanche ou grise. Cela a aussi attiré beaucoup d'attention d'administrateurs de site web. Plus de rampement le freshbot a fait, en particulier sur des pages d'accueil pour des sites dynamiques comme blogs, plus d'administrateurs de site web ont remarqué que leur PageRank ne montrait plus sur la barre d'outils. Il est toujours peu clair si PageRank réel (par opposition à ce que les expositions de barre d'outils) sont aussi indéterminées. La seule façon de juger c'est par les classements pour des mots-clés choisis. Quelques administrateurs de site web ont annoncé des fluctuations massives dans des classements, suggérant que le composant PageRank de l'algorithme se classant ait été en effet cassé(violé). C'était en plus du fait que les pages passeraient voir et de l'index.
6. Bot profond n'a pas apparu depuis la fin d'avril. C'est sans précédent pour bot profond de Google pour être AWOL pour course(direction) de six semaines.
La théorie Y2K+3
Spéculons. La plupart du logiciel fondamental de Google a été écrit dans 1998-2000. Il a été écrit dans C et C ++ pour courir sous Linux. À partir de juillet 2000, Google revendiquait un milliard de pages Web indexées. À novembre 2002, ils revendiquaient 3 milliards. À ce taux d'augmentation, ils seraient maintenant à 3.5 milliards, bien que le compte n'ait pas changé sur leur page d'accueil depuis novembre. Si vous cherchez le mot "@" le vous obtenez un compte de 3.76 milliards. Il est peu clair quel rôle d'autres langues auraient, s'il en est tels dans la production de ce compte. Peut-être chaque langue le fait être le propre lexique et c'est la propre page Web IDs. Mais n'importe quelle voie que vous le coupez, nous s'approche de 4 milliards très bientôt, au moins pour l'Anglais. Avec quelques numéros(nombres) vraisemblablement mis de côté pour le freshbot, il apparaîtrait qu'ils s'écoulent(sortent en courant) la page Web disponible IDs.
Si vous employez un numéro(nombre) d'ID pour identifier chaque nouvelle page sur le tissu, il y a un problème une fois que vous arrivez à 4.2 milliards. Numérote plus haut que cela exigent plus de puissance de traitement et le codage différent. Notre spéculation fait trois suppositions principales : a) Google emploie des fonctions standard pour la langue C dans leur programmation fondamentale; b) quand les programmes de Google ont été d'abord développés quatre ou il y a plus ans, ID unique ont été exigés pour chaque page Web; et c) cela a semblé raisonnable et efficace à ce temps-là pour employer un long entier non signé dans ANSI C. Dans Linux, cette variable est quatre octets de long et a un maximum de 4.2 milliards avant qu'il ne se retourne au zéro. Le suivant intensifient dans des variables numériques sous Linux exige des fonctions différentes standard dans ANSI C et plus de cycles d'UC pour le traitement. Quand les programmes fondamentaux ont été développés pour Google il y a plusieurs ans, il est raisonnable de supposer que l'on n'a pas vu les 4.2 milliards de limite supérieure comme un problème potentiel.
Il est aussi possible que le freshbot, qui a commencé le travail en août 2001, a été assigné son propre bloc de numéros(nombres) d'ID inutilisés de l'association(bassin) de 4.2 milliards. Cela tiendrait compte de l'intégration plus facile des données freshbot avec le profond rampent les données, mais suggéreraient aussi une certaine quantité(somme) d'inefficacité dans l'utilisation de numéros(nombres) disponibles. En effet, freshbot se comporte comme s'il peut seulement tenir un certain numéro(nombre) de pages totales, auxquelles le point il laisse tomber la page la plus vieille dans sa file d'attente de circulaire(tournoi) et le recopie avec une page plus récente d'un site différent. Cette habitude particulière pourrait être un autre symptôme de l'association(bassin) limitée de numéros(nombres) d'ID disponibles.
De n'importe quelle voie vous le coupez, si vous supposez que chaque page Web unique a besoin d'un numéro(nombre) des 4.2 milliards d'association(bassin) avant qu'il ne puisse être inclus dans l'index de Google, alors ou bien Google a des problèmes tout de suite, ou bien il prévoit des problèmes dans le proche avenir et commence à réviser les parties de leur système. Cela pourrait expliquer le comportement récent de Google.
Malgré l'avis de Brett Tabke, ce n'est pas le jeu(pièce) de l'enfant pour ajouter un octet et le faire un entier à cinq octets au lieu d'un entier à quatre octets. L'utilisation d'un octet supplémentaire signifie essentiellement que vous employez un caractère non signé comme un multiplicateur pour 4.2 milliards et ajoutez que sur l'entier pour obtenir votre résultat final. Si l'entier est A et le multiplicateur est B, le nouvel entier est un + (B * 4.2 milliards). Si B est zéro, donc vous obtenez A. Si B est un, vous obtenez des valeurs de 4.2 à 8.4. C'est que vous avez besoin d'une variable de multiplicateur supplémentaire et les lignes supplémentaires de code pour la conversion. (Vous pourriez employer un numéro(nombre) à huit octets dans Linux, mais cela pourrait être moins efficace de point de vue quantitative et emploie évidemment plus d'octets que vous le besoin.) Il n'y a aucune fonction standard dans la programmation des langues qui manipulent des entiers à cinq octets.
Pour quelque chose aussi de base qu'une page Web ID le numéro(nombre), cela implique une révision massive du logiciel de Google. En attendant, vous avez 15,000 Linux des boîtes pour mettre à niveau. Chaque boîte Linux à Google dirige censément un jeu standard de logiciel, pour qu'il puisse être échangé avec d'autres boîtes une fois que les données sont faites un double. Il est sûr de supposer que la page Web ID le numéro(nombre) est omniprésente sur toutes ces boîtes. La mise à niveau doit être faite dans des phases, autrement tout Google va en mode autonome pour peu de temps. La dégradation d'exécution(performance) est tolérable, donnée les circonstances, mais partant - la ligne signifierait une perte instantanée de part de marché. Les rajustements dans la capacité de données pour les index divers doivent être faits aussi, en raison de l'octet supplémentaire par la page Web ID.
Comme nous avons exposé au commencement de cette page, tous c'est spéculatif. Puisque Google ne nous dira pas ce qui se passe, nous sommes forcés d'encourager la spéculation sauvage dans l'espoir que Google le verra comme dans leurs intérêts pour être plus prochain de ce qu'ils sont jusqu'à.
Google croit qu'il n'est aucun de notre affaire. Mais ils sont faux. C'est notre affaire. Nous n'avons pas demandé à Google de devenir le courtier mondial de l'information; il est juste arrivé cette voie.
