David Madore's WebLog: 2014-09

Vous êtes sur le blog de David Madore, qui, comme le reste de ce site web, parle de tout et de n'importe quoi (surtout de n'importe quoi, en fait), des maths à la moto et ma vie quotidienne, en passant par les langues, la politique, la philo de comptoir, la géographie, et beaucoup de râleries sur le fait que les ordinateurs ne marchent pas, ainsi que d'occasionnels rappels du fait que je préfère les garçons, et des petites fictions volontairement fragmentaires que je publie sous le nom collectif de fragments littéraires gratuits. • Ce blog eut été bilingue à ses débuts (certaines entrées étaient en anglais, d'autres en français, et quelques unes traduites dans les deux langues) ; il est maintenant presque exclusivement en français, mais je ne m'interdis pas d'écrire en anglais à l'occasion. • Pour naviguer, sachez que les entrées sont listées par ordre chronologique inverse (i.e., la plus récente est en haut). Cette page-ci rassemble les entrées publiées en septembre 2014 : il y a aussi un tableau par mois à la fin de cette page, et un index de toutes les entrées. Certaines de mes entrées sont rangées dans une ou plusieurs « catégories » (indiqués à la fin de l'entrée elle-même), mais ce système de rangement n'est pas très cohérent. Le permalien de chaque entrée est dans la date, et il est aussi rappelé avant et après le texte de l'entrée elle-même.

You are on David Madore's blog which, like the rest of this web site, is about everything and anything (mostly anything, really), from math to motorcycling and my daily life, but also languages, politics, amateur(ish) philosophy, geography, lots of ranting about the fact that computers don't work, occasional reminders of the fact that I prefer men, and some voluntarily fragmentary fictions that I publish under the collective name of gratuitous literary fragments. • This blog used to be bilingual at its beginning (some entries were in English, others in French, and a few translated in both languages); it is now almost exclusively in French, but I'm not ruling out writing English blog entries in the future. • To navigate, note that the entries are listed in reverse chronological order (i.e., the most recent is on top). This page lists the entries published in September 2014: there is also a table of months at the end of this page, and an index of all entries. Some entries are classified into one or more “categories” (indicated at the end of the entry itself), but this organization isn't very coherent. The permalink of each entry is in its date, and it is also reproduced before and after the text of the entry itself.

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]

Entries published in September 2014 / Entrées publiées en septembre 2014:

↓Entry #2229 [older| permalink|newer] / ↓Entrée #2229 [précédente| permalien|suivante] ↓

(vendredi)

J'ai de nouveau le téléphone !

Ma ligne téléphonique est revenue cet après-midi à 14:39, après seulement 11 jours d'interruption (en fait, 262.5 heures), alléluia !

Maintenant il ne me reste plus qu'à remettre toute mon installation informatique en ordre (par exemple, la reconnexion a eu lieu juste après que j'ai fait basculer le serveur DNS maître de mes domaines comme madore.org vers une autre machine).

↑Entry #2229 [older| permalink|newer] / ↑Entrée #2229 [précédente| permalien|suivante] ↑

↓Entry #2228 [older| permalink|newer] / ↓Entrée #2228 [précédente| permalien|suivante] ↓

(vendredi)

Capteur de proximité cassé

Puisque je suis dans une série où je raconte mes problèmes de téléphone (saga de la ligne fixe cassée depuis 12 jours — et qui continue à ne pas marcher : 1, 2 et 3), j'en profite pour signaler celui-ci, qui n'est certes pas catastrophique mais est quand même gênant : le capteur de proximité de mon téléphone mobile (Nexus 4) est cassé.

Le capteur de proximité, présent sur la plupart des smartphone, c'est le gadget qui détecte que le téléphone est collé contre votre oreille, et qui, dans ces circonstances, désactive l'écran pendant un appel : ceci évite qu'on fasse involontairement des commandes en touchant l'écran avec la joue, par exemple celle de raccrocher. C'est une excellente idée, sauf quand le capteur en question ne marche pas. Enfin, il y a deux façons de ne pas marcher, et mon capteur a évidemment choisi la pire : il pourrait ne pas détecter ma tête quand elle est là, mais il fait le contraire, il la détecte en permanence.

Autrement dit, dès que je commence à passer un appel, l'écran se désactive, et je n'ai donc pas de moyen de raccrocher (sauf en éteignant complètement le téléphone), ni d'accéder aux touches numériques qui servent pour communiquer avec les serveurs vocaux. C'est particulièrement problématique pour la consultation de mon répondeur : pas de moyen de passer au message suivant, de réécouter un message, de revenir en arrière, etc. — puisque toutes ce fonctions sont accessibles en appuyant sur des touches. Je ne peux donc véritablement consulter mon répondeur que depuis un téléphone fixe, ce qui (a) me coûte de l'argent, et (b) ne m'est pas possible en ce moment (comme on le sait, ma ligne fixe est HS, et mon téléphone de bureau ne me permet pas de consulter le répondeur de mon mobile). J'arrive quand même à raccrocher : le capteur de proximité a des instants de lucidité, au pire je peux éteindre le téléphone de force en gardant le bouton on/off appuyé pendant dix secondes, ou encore activer l'option d'accessibilité raccrocher sur appui du bouton on/off ; mais en tout cas la situation est assez absurde.

Contrairement à d'autres appareils, le Nexus 4 ne permet pas de recalibrer un capteur de proximité trop sensible (ce capteur ne sait renvoyer que deux valeurs : tête éloignée ou tête présente). Il y a bien des applications qui traînent prétendant résoudre le problème en forçant un réveil permanent de l'écran pendant les appels, mais je ne fais aucune confiance à des applications confidentielles dont je ne sais rien du développeur et dont le code source n'est pas publié.

C'est d'autant plus absurde que le téléphone a des boutons physiques : il serait évident et raisonnable de faire en sorte que si l'utilisateur appuie sur un de ces boutons (disons, le bouton d'alimentation), le capteur de proximité soit ignoré pendant dix secondes ou quelque chose de la sorte. Ou simplement de prévoir de désactiver la fonction éteindre l'écran si le capteur de proximité détecte la présence de la tête. Je viens de soumettre un bug-report Android dans ce sens, mais soumettre un bug-report sur Android a le même effet qu'écrire à Orange : c'est purement défoulatoire, il ne faut pas espérer une seule seconde que ce qu'on écrit sera pris en compte.

Le meilleur contournement que j'aie trouvé pour l'instant (je n'y ai pensé qu'aujourd'hui, en fait), c'est de brancher les écouteurs externes : miraculeusement, quelqu'un a eu la bonne idée de désactiver le capteur de proximité dans ces circonstances. Mise à jour : En fait, il semble que ça ne marche plus sous CyanogenMod 11 / Android KitKat. ☹️

Sinon, la bonne solution serait pour moi de recompiler l'application com.android.phone (i.e., le téléphone) pour en retirer tout le code qui tient compte du capteur de proximité (ou ajouter la fonction qui permet au bouton on/off d'activer l'écran pour dix secondes, ou quelque chose comme ça). Malheureusement, même si le code source est fourni donc c'est possible en théorie, en pratique, recompiler une application système Android est très difficile : je sais que je m'étais arraché les cheveux à trouver comment recompiler l'application clavier, je me sens assez découragé à l'idée de recommencer pour l'application de téléphonie. (Surtout que chacune de ces petites réparations que je peux faire sur mon Android va signifier un long moment à passer à chaque nouvelle mise à jour du système pour refaire toutes les réparations qui auront été écrasées par la mise à jour.)

↑Entry #2228 [older| permalink|newer] / ↑Entrée #2228 [précédente| permalien|suivante] ↑

↓Entry #2227 [older| permalink|newer] / ↓Entrée #2227 [précédente| permalien|suivante] ↓

(mercredi)

Mes douleurs mystérieuses à la tête

Dans la série Les passionnantes aventures de Ruxor hypocondriaque, je vous avais parlé de mon cœur, maintenant je vais vous parler de ma tête.

J'ai toujours eu (depuis que je suis petit) des maux de têtes en tous genres, jamais très douloureux (sauf les deux fois où j'ai fait une migraine ophtalmique), ni même terriblement fréquents, mais en revanche assez impressionnants par leur diversité : j'ai eu des maux de tête pulsatiles, des maux de tête sourds et constants, des maux de tête localisés, des maux de tête généralisés, j'ai l'impression d'avoir essayé tout un menu de maux de têtes différents. Globalement j'en ai plutôt moins que quand j'étais ado.

Mais il y a une sorte qui est apparue plutôt récemment et que je trouve assez mystérieuse, ce sont les maux de tête extérieurs au crâne, c'est-à-dire, au niveau du cuir chevelu.

Cela commence par une douleur assez soudaine et qui semble intérieure au crâne, mais très localisée dans celui-ci, et au bout de quelques heures ou peut-être d'une journée l'origine de la douleur apparaît clairement comme extérieure au crâne. Cela peut être à n'importe quel endroit sous les cheveux ou parfois au niveau du front. Parfois, mais pas toujours, il y a une petite bosse sensible au toucher qui apparaît sous la peau, de quelques millimètres de diamètre (et je suis sûr que je ne me suis pas cogné). Il n'y a pas de changement de couleur de la peau. La douleur est normalement, en intensité et en qualité, intermédiaire entre celle provoquée par un hématome et un bouton infecté : parfois elle est plus forte, et en tout cas elle a tendance à venir par à-coups qui durent quelques secondes et sont séparés de plusieurs dizaines de secondes ou minutes. Cela provoque chez moi l'envie très forte d'appuyer sur l'endroit douloureux ou de le masser — mais je ne sais pas si c'est une bonne idée. Parfois j'ai deux ou trois points douloureux de la sorte, proches les uns des autres, qui apparaissent en même temps.

Normalement cela passe en un jour ou deux, mais j'ai une douleur de ce genre qui dure depuis ce week-end et qui a plutôt empiré depuis hier et qui m'a réveillé plusieurs fois cette nuit. C'est loin d'être insupportable, mais ça me gêne vraiment pour me concentrer, un peu comme si quelqu'un me pinçait de façon répétée.

(Peut-être que c'est mon stress des derniers jours qui joue ?)

Ceci me fait penser, d'ailleurs, que mon généraliste / médecin traitant a cessé d'exercer (plus exactement, il s'est vendu au côté obscur de la médecine en devenant expert pour une compagnie d'assurance). Il faut donc que j'en trouve un autre dans le coin. Ce qui n'est pas évident, un hypocondriaque ayant besoin d'un médecin qui le comprenne, c'est-à-dire qui sache être rassurant sans être méprisant, qui écoute ses doléances sans y croire automatiquement mais sans non plus les ignorer. Mon généraliste a une remplaçante officielle, mais la seule fois que je l'ai vue (elle le remplaçait temporairement, pour l'été), elle a clairement montré qu'elle n'avait pas ces qualités.

↑Entry #2227 [older| permalink|newer] / ↑Entrée #2227 [précédente| permalien|suivante] ↑

↓Entry #2226 [older| permalink|newer] / ↓Entrée #2226 [précédente| permalien|suivante] ↓

(mercredi)

Toujours rien

Neuf jour après le début de l'incident, ma ligne téléphonique n'a toujours pas été rétablie, pas plus que mon accès ADSL. La situation a même empiré : nous n'avons toujours pas la tonalité, mais au moins, jusqu'à hier, quand on nous appelait, notre ligne sonnait occupée (i.e., en dérangement), maintenant elle sonne normalement — nos correspondants ne sont donc même pas prévenus que notre ligne est en dérangement, ni nous qu'on cherche à nous joindre ; et pour l'ADSL, jusqu'à hier le modem captait un embryon de sychronisation qui lui permettait occasionnellement d'avoir une connexion (cf. le graphique sur l'entrée précédente, que j'ai tenu à jour depuis), maintenant nous n'avons plus rien : tout se passe exactement comme si nos prises téléphoniques étaient totalement débranchées. Pas non plus la moindre communication de la part d'Orange (pas de courrier, le service des dérangements continue à nous envoyer sur un message préenregistré qui ne dit rien, et leur site Web continue de prévoir un rétablissement complet au plus tard le 17/09/2014 fin de matinée insensible au fait que ce message est de plus en plus ridiculement faux).

Je dois avouer que si on m'avait dit qu'un quartier entier d'une grande métropole comme Paris pouvait, en 2014, se trouver complètement privé de téléphone et d'accès Internet, pendant neuf jours and counting sans que ça n'émeuve qui que ce soit d'autre que moi, sans qu'il y ait la moindre communication sur l'incident ou sur sa durée prévisible, je n'y aurais pas cru une seconde.

Je suis aussi impressionné par l'absence totale de recours qui s'offre à moi. J'ai contacté l'ARCEP, qui m'a répondu assez à côté de la plaque, mais en tout cas en disant clairement que ça ne les concerne en aucun cas, mon seul interlocuteur possible est mon opérateur — celui-là même qui fait tout pour ne pas être contactable. Il existe un Médiateur des Télécoms, mais son rôle est manifestement pensé pour les cas de désaccords de facturation, pas pour les incidents ou la communication sur incident : entre autres, on ne peut le saisir que deux mois après avoir contacté l'opérateur (vous savez, celui que je ne peux pas contacter parce qu'il est incontactable) et un mois après l'avoir recontacté par écrit (bon, là au moins j'ai trouvé une adresse à laquelle j'ai envoyé une LRAR, mais je n'en attends pas grand-chose). Au civil je peux peut-être vaguement espérer obtenir le remboursement du prorata de mon abonnement téléphonique, autrement dit trois clopinettes dont je n'ai rien à foutre et qui ne couvrent pas le centième des emmerdes qui me sont causés par l'incident ; cela ne vaut certainement pas la peine que j'engage les frais exorbitants représentés par le service d'un avocat pour récupérer ces trois clopinettes. Comme il n'y a pas de class actions en France, le fait que des centaines ou des milliers de personnes soient touchées ne change rien à l'affaire.

Concernant ma connexion ADSL (qui m'est beaucoup plus importante que ma ligne analogique traditionnelle), la situation est encore plus merdique, parce que je n'ai même pas le droit de m'adresser à Orange à son sujet : je suis client d'un opérateur (Nerim) qui sous-traite à SFR la gestion de ses connexions ADSL, qui (comme tout le monde, obligatoirement) sous-traite à Orange la gestion de la boucle locale. Du coup, tout ce que je peux faire c'est communiquer avec Nerim pour leur demander de demander à SFR de poser à Orange la question de combien de temps l'incident durera : je me sens comme le héros de la nouvelle Devant la Loi de Kafka, confronté à trois Gardiens entre moi et ma ligne ADSL, et n'ayant le droit de communiquer qu'avec le premier. En tout cas, je n'ai pas réussi à faire passer le message il y a un problème avec ma ligne, je suis sûr que ça ne vient pas de mon côté, pouvez-vous transmettre à vos sous-traitants la question de combien de temps le dérangement va durer ? — et je me suis surtout retrouvé coincé dans un dialogue de sourds.

Le plus ironique, c'est que si la petite plaisanterie continue, je ne vais pas avoir d'autre solution que de prendre un abonnement fibre comme connexion de secours quand l'ADSL tombe en panne (oui, c'est bizarre de le faire dans ce sens-là, mais ce n'est pas le débit qui m'intéresse dans la connexion Internet), et pour ce qui est de la fibre, vue la façon dont les opérateurs se sont partagés le gâteau, il semble que je n'aie pas d'autre choix que de faire appel à… Orange. Chouette.

Mise à jour : Mon poussinet a réussi a parler à un humain au service des dérangements (l'astuce était d'appuyer sur la touche ‘#’ face au serveur vocal — je ne sais pas comment il a trouvé ça). Maintenant on nous parle d'un rétablissement de notre ligne pour le… 30 septembre.

↑Entry #2226 [older| permalink|newer] / ↑Entrée #2226 [précédente| permalien|suivante] ↑

↓Entry #2225 [older| permalink|newer] / ↓Entrée #2225 [précédente| permalien|suivante] ↓

(samedi)

Pourquoi ma ligne téléphonique est HS (et sur la communication d'Orange)

Ma ligne téléphonique fixe est hors service depuis 5 jours maintenant (ainsi que celles de toute une partie du quartier, même si je ne sais pas exactement quel est le périmètre recouvert ; mais quand je vois que le marchand de vins du bout de la rue a mis une petite affichette expliquant qu'il ne peut plus prendre les cartes bancaires pour des raisons techniques, je me doute bien que c'est à cause de ça).

J'ai réussi à savoir la cause du problème : c'est un vieux câble d'alimentation en plomb de 1800A qui a cassé au niveau du 45 rue Bobillot, et qui est maintenant en train d'être changé (par un câble qui ne soit pas en plomb !). J'avoue que je n'avais pas idée qu'on avait besoin de courants aussi importants pour alimenter les lignes téléphoniques (1800A, ça suffit à fournir du 60mA à 30000 lignes en parallèle, soit la totalité des lignes de mon central répartiteur), même s'il s'agit de tensions assez faibles, quelque chose comme 48V. Et je ne savais pas non plus qu'on avait encore des câbles en plomb qui fonctionnaient.

Mais bon, ce dont je veux me plaindre, ce n'est pas que cet incident ait eu lieu, ni de sa durée, c'est de l'absence totale de communication officielle de la part d'Orange sur la nature et les causes du problème (les informations que je viens de donner au paragraphe précédent) ou sur la durée d'interruption à prévoir. Comme je l'ai écrit dans l'entrée précédente, le service des dérangements (le 1013) ne donne aucune information, le site web orange.fr n'en a pas plus — pire, il promet un retour à la normale pour une date dans le passé, c'est-à-dire que personne chez Orange n'a trouvé les deux minutes pour mettre à jour le message quand on s'est aperçu que le problème était plus grave que prévu.

Quand tout un quartier est touché par une interruption de la boucle locale de téléphone, on peut peut-être au minimum trouver le moyen de mettre à jour un site Web et un répondeur téléphonique avec quelques explications, voire d'envoyer un agent coller des petites affiches dans ce quartier ! J'ai essayé d'assurer moi-même le minimum en postant des feuilles explicatives sur des tableaux d'affichage et à la porte de quelques immeubles au hasard dans le coin, mais comme je ne sais pas au juste qui est touché et que je n'avais par ailleurs que peu de temps, c'est une goutte d'eau — quoi qu'il en soit, il est hallucinant que ce soit moi qui me charge, au final, de la communication de la société Orange (ou, en fait, de tous les opérateurs sur ligne de cuivre, puisque c'est la totalité de la boucle locale qui est touchée : voir plus bas pour l'ADSL).

Je vais envoyer un mail à l'ARCEP pour attirer leur attention là-dessus, mais bon, j'imagine que l'ARCEP est trop débordée pour s'occuper des remarques de péquenots comme moi.

Comment ai-je réussi à avoir l'information que je cherchais ? J'ai envoyé un fax directement au service d'Orange qui s'occupe de l'entretien de la boucle locale à Paris (leur numéro n'est, bien sûr, pas communiqué au public, mais avec un peu de Google-fu, on peut arriver à le dénicher). Peut-être le fait que le fax était à l'en-tête de Télécom ParisTech a joué, mais en tout cas on m'a répondu très gentiment (sur mon mobile), et je suis infiniment reconnaissant à la personne qui a pris le soin de le faire. Bien sûr, j'aurais aussi pu me rendre compte que les techniciens d'Orange qui sont apparus à deux pas de chez moi et ont commencé à s'affairer sous le trottoir n'étaient peut-être pas là par hasard, mais comme leur camionnette porte une pub pour la fibre par Orange, on n'imagine pas forcément qu'ils sont là pour entretenir le cuivre.

[Graphe de l'état de ma connexion ADSL sur 8 jours]J'avoue que je ne comprends pas bien pourquoi l'absence de l'alimentation qui est censée ne concerner que la ligne analogique traditionnelle affecte la connexion ADSL (je pensais que les lignes ADSL nues, en cas de dégroupage total, n'étaient pas alimentées). Je comprends encore moins pourquoi ça fonctionne très légèrement, et selon un motif pas du tout clair : j'ai tracé ci-contre l'historique de ma connexion ADSL sur 192 heures (depuis lundi 15 à 16h jusqu'à [mise à jour] mardi 23 à 16h) d'après les données fournies par mon opérateur : en vert, je suis connecté (certes à une vitesse épouvantablement basse, quelque chose comme 160kbit/s en upload), en rouge je ne le suis pas (en fait, parce que le modem n'arrivait pas à établir la synchro). Comme mon routeur (allumé 24 heures sur 24) essaie en permanence d'établir la connexion (et que le modem derrière essaie en permanence de garder la synchro), à part entre le 17 septembre vers 22h et le 18 septembre vers 7h où j'ai coupé les tentatives parce que je pensais que ça ne servait à rien, on peut dire que c'est un graphique du fait que des tentatives désespérées de maintenir une connexion ADSL réussissent ou non. Pourquoi diable a-t-il cette allure de code barre alors que la ligne était désalimentée tout le temps ?

Je pense que la réponse est quelque chose comme ceci : l'ADSL n'a pas besoin de l'alimentation pour fonctionner, mais soit il est calibré pour tenir compte de sa présence (parce que la ligne est censée être alimentée) soit un filtre contre le bruit nécessite une alimentation qui a aussi été coupée, et en tout cas on se retrouve avec une qualité de ligne très mauvaise, mais pas absolument nulle. Ensuite, c'est un peu un hasard du fait que le modem réussisse à négocier une vitesse assez faible (et peut-être hors spécifications ADSL ?) pour obtenir quand même une connexion. Peut-être, par ailleurs, que le fait que d'autres usagers fassent aussi usage de leur ligne ADSL sur des fils voisins joue-t-il dans le bruit observé. Mais bon, cette explication partielle ne rend pas vraiment compte du fait que la connexion a pu fonctionner pendant des heures d'affilée, et ensuite ne plus fonctionner également pendant des heures.

↑Entry #2225 [older| permalink|newer] / ↑Entrée #2225 [précédente| permalien|suivante] ↑

↓Entry #2224 [older| permalink|newer] / ↓Entrée #2224 [précédente| permalien|suivante] ↓

(mercredi)

Ma ligne téléphonique a été coupée

Avant-hier (lundi 15), assez brutalement à 16h03, notre connexion ADSL a commencé a avoir des vapeurs : déconnexions toutes les quelques minutes, avec au final environ 2/3 du temps connecté et un débit pourri. Je me suis dit que c'était notre fournisseur d'accès qui avait des problèmes techniques (ça lui arrive occasionnellement). Hier matin, les problèmes semblaient un peu atténués, mais ils sont revenus dans l'après-midi : j'ai commencé à soupçonner que le modem ADSL était mourant ce qui m'a déjà causé des problèmes semblables. Mon poussinet a appelé le support technique du fournisseur d'accès, qui a convenu que le bruit était anormalement élevé sur la ligne et a dit qu'il faudrait essayer de faire un test sans filtre (on ne pouvait pas immédiatement puisque personne n'était à la maison), et en attendant il a dit qu'il allait rebooter la « carte » (je ne sais pas ce que c'est) pour voir si ça améliorait les choses. Ça ne les a pas améliorées et, en fait, nous avons totalement perdu la connexion à ce moment.

Je suis rentré à la maison (hier mardi 16 après-midi, donc) et j'ai constaté que non seulement nous n'avions plus du tout l'ADSL (pas de synchro), mais, en fait, nous n'avions même plus la tonalité téléphonique. Notre ligne est complètment morte.

J'ai appelé le service des dérangements au 1013, je suis tombé sur un répondeur vocal qui m'a appris que le service était connu et affectait plusieurs clients, que des techniciens travaillaient dessus, et que je pourrais en savoir plus sur leur site Web, rubrique infos incidents. Celui-ci me dit :

Vos services sont interrompus suite à un incident sur le réseau Orange. Nous prévoyons un rétablissement complet au plus tard le 17/09/2014 fin de matinée. Nous vous prions de nous excuser pour la gêne occasionnée.

Bon, pourquoi pas. Ce matin (mercredi 17), au réveil (vers 7h), la synchro ADSL était revenue, certes avec un débit complètement pourri (environ 1/6 de ce que nous avions normalement, dans les deux sens), mais c'est déjà mieux que rien et c'est possible qu'un équipement ait décidé de baisser la qualité de la ligne par sécurité — d'ailleurs, rien que rebooter le modem a amélioré les choses d'un facteur 2 (ce qui restait à environ 1/3 de ce que nous avions normalement).

Là où ça devient moins drôle, c'est que la ligne a été de nouveau coupée dans l'après-midi (mercredi 17). De nouveau plus de synchro ADSL et plus de tonalité. Et surtout, là où je trouve que France Télécom Orange se fout de moi, c'est que le message sur leur site est toujours exactement le même et promet un rétablissement pour au plus tard un instant dans le passé. Et pas un mot sur la cause technique du problème : des travaux auraient-ils coupé les fils de cuivre ? un incendie dans le central aurait-il endommagé des équipements ? autre chose ? j'aimerais bien le savoir, moi, au lieu qu'on me laisse comme un con avec la phrase qui ne veut rien dire un incident sur le réseau Orange. Même si ça doit prendre un peu de temps des techniciens chargés de s'occuper du problème, et donc en retarder de quelques minutes la résolution, ça vaut la peine d'expliquer ce qui se passe (par exemple, si on nous dit qu'il s'agit des travaux en cours rue Chéreau qui auraient endommagé les lignes, une meute d'usagers en colère peut aller engueuler les gens qui ont fait ça, au moins ça nous défoulera). En l'état actuel, je sais juste que je n'ai plus le téléphone ni accès à Internet (de chez moi — et comme mon mobile n'y capte rien, je ne peux même pas m'en servir comme secours), et je ne sais ni pourquoi ni pour combien de temps ni qui est responsable.

Et je me rends surtout compte de combien je ne peux rien faire sans cet accès Internet. Dès que je veux noter quelque chose sur mon agenda, par exemple, je me rends compte que mon agenda est sur mon ordinateur à la maison, auquel je n'ai plus accès depuis mon bureau : bien sûr, ce n'est pas très difficile d'aller le chercher (surtout que je travaille à 10 min à pied de chez moi), mais dès que je reviens, je me rends compte que j'ai besoin d'un autre fichier (un article de maths au format électronique), puis d'un autre (un livre idem), puis d'un autre (mon fichier de numéros de téléphone), et c'est un peu technique de prendre mes quatre disques durs pour aller au bureau. J'ai donc passé trois jours complètement improductifs à essayer de guetter les quelques minutes où la connexion fonctionnait miraculeusement pour en faire usage.

Inutile de dire que ma fatigue colossale a augmenté d'un bon cran dans l'histoire.

Suite : (70 heures après le début des problèmes) : toujours pas de résolution en vue, ni la moindre explication du problème ; le site orange.fr continue d'afficher mensongèrement qu'ils prévoient un rétablissement complet pour hier matin. • J'ai envoyé un fax à l'Unité d'Intervention de Paris d'Orange (en googlant un peu, on trouve leurs coordonnées…), on va voir si quelqu'un a la décence d'y répondre. • Finalement, oui, j'ai eu une réponse : voir l'entrée suivante.

↑Entry #2224 [older| permalink|newer] / ↑Entrée #2224 [précédente| permalien|suivante] ↑

↓Entry #2223 [older| permalink|newer] / ↓Entrée #2223 [précédente| permalien|suivante] ↓

(lundi)

La fonction de Fabius

[Graphe de la fonction de Fabius sur [0;24]]

J'ai déjà raconté trente-douze fois sur ce blog, et je continuerai à radoter à ce sujet, qu'une de mes motivations à être mathématicien, c'est de pouvoir visiter le petit musée des objets mathématiques remarquables, admirables, ou simplement curieux. L'objet dont je veux parler ici est plus amusant que fascinant, ce qui ne l'empêche pas d'être élégant. Il s'agit d'une fonction réelle définie par un certain J. Fabius (j'ignore le prénom ou s'il y a un lien de parenté avec l'actuel ministre français des affaires étrangères) dans une publication de 1966.

[Graphe de la fonction de Fabius sur [0;1]]Voici une première définition possible : on appelle Un (pour n≥1 entier) une suite de variables aléatoires indépendantes et uniformément réparties dans [0;1], et on pose Z = ∑n Un/2n (remarquer que Z est aussi une variable aléatoire à valeurs dans [0;1]). Alors la fonction de Fabius f sur [0;1] est la distribution de probabilité de la variable Z (c'est-à-dire que f(t), pour t∈[0;1], est la probabilité que Zt). (Le graphe en est tracé ci-contre à gauche.) Pour souligner que cette loi de probabilité n'est pas complètement bizarre ou surgie de l'espace, on peut remarquer que si au lieu d'une variable Un uniformément répartie dans [0;1] on utilisait des variables Vn (toujours indépendantes et) uniformément réparties dans {0;1} (c'est-à-dire valant 0 avec probabilité ½ et 1 avec probabilité ½), alors ∑n Vn/2n serait uniforément répartie dans [0;1] puisque la construction revient à tirer chaque bit de cette variable à pile ou face indépendamment.

Pour compléter f aux réels positifs, on décrète alors que f(t+1) = 1−f(t) pour t∈[0;1], et que f(t+2k) = −f(t) pour t∈[0;2k] (lorsque k≥1 est entier). Le caractère naturel de ce prolongement va apparaître dans ce qui suit. (Le graphe de la fonction ainsi prolongée est tracé en haut de cette entrée.)

La fonction possède un lien très fort avec la suite de Morse-Thue, qui peut être définie comme la suite dont le n-ième terme vaut 0 ou 1 selon que le nombre de 1 dans l'écriture binaire de n (=le poids de Hamming H(n) de n) est pair ou impair ; si on préfère, la suite de Morse-Thue est celle qui s'obtient en partant d'un 0 et en effectuant un nombre infini de fois le remplacement simultané de 0 par 01 et de 1 par 10 (cf. l'article Wikipédia). Comme on peut le voir sur le graphe ci-dessus (et ce n'est pas difficile avec la définition que j'ai donnée), le signe de f sur l'intervalle [2n;2n+1] vaut + ou − selon que la valeur du n-ième terme de la suite de Morse-Thue est 0 ou 1.

[Construction de la fonction de Fabius]Voici une autre définition possible de la fonction de Fabius, dans cet esprit : on appelle d'abord f0 la fonction qui sur l'intervalle [2n;2(n+1)[ vaut +½ ou −½ selon que la valeur du n-ième terme de la suite de Morse-Thue est 0 ou 1 ; puis par récurrence sur k, on appelle fk+1(x) l'intégrale de fk(t) pour t allant de 0 à 2x. La suite de fonctions en question converge alors uniformément vers f. (Ci-contre, j'ai tracé f0 en vert, f1 en un vert subtilement différent, f2 en caca d'oie et f en bleu.)

[Graphe de la fonction de Fabius sur [0;24] et de sa dérivée]Qu'on utilise l'une ou l'autre construction, il n'est pas très difficile de voir que la fonction de Fabius vérifie l'équation fonctionnelle surprenante suivante : f′(t) = 2f(2t) pour tout t≥0. (Pour l'illustrer, j'ai tracé la fonction de Fabius accompagnée de sa dérivée f′.) Notons qu'il ne s'agit pas d'une équation différentielle, puisque la valeur de la dérivée est reliée à la valeur de la fonction en un autre point ; d'ailleurs, il n'y a pas unicité de la solution de cette équation : la fonction nulle la vérifie aussi (avec, d'ailleurs, la même « condition initiale » f(0)=0) ; néanmoins, l'équation en question et la connaissance de la fonction f sur [0;1] définit de façon unique sa valeur sur tous les réels positifs.

Puisque f(0)=0, l'équation fonctionnelle f′(t) = 2f(2t) implique de façon assez évidente que toutes les dérivées de f en 0 valent 0 : la fonction de Fabius est infiniment plate en 0. En fait, il aussi facile de voir qu'en n'importe quel rationnel dyadique, toutes ses dérivées s'annulent à partir d'un certain rang : par conséquent, f n'est pas égale à la somme de sa série de Taylor développée en un dyadique, et comme les dyadiques sont denses dans les réels, f est une fonction C mais nulle part analytique (c'était la motivation de son introduction). On peut aussi se persuader que, en une valeur comme 1/3, la série de Taylor de f a un rayon de convergence nul (parce que la dérivée r-ième de f est donnée par f(r)(t) = 2r(r+1)/2·f(2r·t)).

Mais il y a quantité de choses que j'ignore. Par exemple, expérimentalement, il semble que f(1/4) = 5/72, et je ne sais pas le prouver (pas que j'aie essayé, du reste). Il serait tentant de penser, pour l'expliquer, qu'il y ait une relation entre f(t) et f(t+½) comme il y en a entre f(t+2s) pour tout s≥0 entier, mais une telle relation ne peut pas, il me semble, être algébrique, donc je ne sais pas ce qu'on est en droit d'espérer. Je ne sais pas non plus si on peut dire quelque chose d'intelligent de la valeur f(1/3) ≈ 0.180165114801 (cette valeur n'évoque rien à Google, mais Google n'est pas très bon pour faire du calcul symbolique inverse ; elle n'évoque rien non plus à ce site ni à Wolfram Alpha). Pourtant, l'écriture binaire du nombre 1/3 est suffisamment remarquable pour qu'on soit en droit de penser que la fonction f devrait en faire quelque chose d'intéressant.

Enfin, je dois signaler que je ne sais pas vraiment calculer les valeurs de f de façon efficace. Le mieux que je connaisse est une expression de fk que j'écris en MathML pour ceux dont le navigateur le supporte :

f k ( x ) = 2 k(k+1)/2 k! 0j2k1x cj ( x j2k1 ) k c0 = 12 et cj = 12 ( (1) H(j) (1) H(j1) ) si j>0

(j'ai noté H(j) pour le poids de Hamming de j). Mais cette équation n'est pas vraiment satisfaisante parce qu'elle ne relie pas fk+1 à fk, par exemple par une sorte de dichotomie. Bref, la fonction de Fabius reste assez mystérieuse à mes yeux.

Ajout : dans un même esprit, voir aussi la fonction ‘?’ [point d'interrogation] de Minkowski dont j'avais déjà parlé autrefois.

Ajout : voir aussi la réponse de François Guéritaud en commentaire () où il explique comment calculer la valeur et les dérivées successives de f aux dyadiques en comparant des intégrales de la fonction et de ses polynômes osculateurs, ce qui répond en partie à mes interrogations (notamment sur le fait que f(1/4)=5/72). • Surajout : voir ce petit texte de Haugland qui explique essentiellement la même chose.

↑Entry #2223 [older| permalink|newer] / ↑Entrée #2223 [précédente| permalien|suivante] ↑

↓Entry #2222 [older| permalink|newer] / ↓Entrée #2222 [précédente| permalien|suivante] ↓

(dimanche)

Comment m'éviter de dormir sur le dos ?

Je suis infiniment fatigué en ce moment. Nerveusement avant tout, parce que l'été n'a rien eu de reposant, j'ai l'impression de n'avoir fait que rattraper des affaires en regard et gérer des ennuis qui me tombaient dessus ; et les quelques jours où j'ai voyagé m'ont encore plus fatigué (je trouve les déplacements terriblement stressants, j'aurais besoin de temps pour décomprimer un peu après, mais je ne l'ai pas eu). Et surtout, j'attaque une rentrée compliquée — mon emploi du temps est désastreux, je dois faire avec des horaires irréguliers et malcommodes et pas la moindre possibilité de souffler un peu avant Noël (où je devrai de nouveau affronter un voyage fatigant). Un nombre terrifiant de gens comptent sur moi pour faire des choses diverses et variées, dont je n'aurai évidemment pas le temps de mener à bien le quart, (parfois j'ai presque l'impression d'être harcelé), et dès que c'est moi qui essaie de demander quelque chose à d'autres, soit je n'arrive pas à me décharger comme je le voudrais, soit je passe encore plus de temps à demander (ou à trouver à qui demander) que je n'en passerais à faire les choses moi-même. Bref, je suis débordé et épuisé, et bien seul avec mes tracas.

Mais je suis aussi fatigué physiquement, ce qui n'aide pas. Mon poussinet se contente de me dire si tu es fatigué, il faut te coucher à chaque fois que je me plains d'être à bout, ce en quoi il n'a peut-être pas tord, mais je dors déjà beaucoup (ce qui n'aide pas à faire des choses dans la journée et à être moins débordé, bien sûr).

Un aspect du problème est certainement que je respire mal pendant la nuit (j'ai probablement une forme mineure d'apnée du sommeil), dès que je me mets sur le dos. Mon poussinet — du moins s'il se trouve être réveillé — me pousse régulièrement pendant la nuit pour me mettre sur le côté, mais parfois je suis très entêté à dormir sur le dos et à ronfler voire m'étouffer. Il a aussi souvent essayé de me bloquer avec une peluche, mais je la repousse sans ménagement.

Je pourrais essayer, par exemple, de dormir avec un sac à dos (en essayant de mettre quelque chose dans le sac à dos pour que ce soit juste assez inconfortable pour que je ne sois pas tenté de dormir sur le dos, mais pas assez pour me faire mal), mais j'ai peur que ça m'empêche purement et simplement de dormir. L'ennui c'est que, si je dors bien sur le côté, j'éprouve régulièrement le besoin de changer de côté au cours de la nuit (selon la manière dont mes narines se bouchent), c'est probablement au cours de ces changements de côté pas bien achevés que je me retrouve sur le dos : il faut que j'invente une façon de m'empêcher de me mettre sur le dos qui ne m'empêche pas pour autant de passer du côté gauche au côté droit ou inversement, et là je manque d'idée. (Certes, on peut changer de côté en basculant sur le ventre plutôt que sur le dos, mais c'est beaucoup moins naturel vu que quand je suis allongé sur le côté gauche je suis aussi décalé vers la droite de l'oreiller et vice versa.)

↑Entry #2222 [older| permalink|newer] / ↑Entrée #2222 [précédente| permalien|suivante] ↑

↓Entry #2221 [older| permalink|newer] / ↓Entrée #2221 [précédente| permalien|suivante] ↓

(mercredi)

Je découvre encore un bug improbable

Ayant installé de nouveaux disques durs dans le PC chez mes parents, je fais ce que je fais régulièrement, à savoir compiler un Firefox. La compilation échoue sur quelque chose que je ne comprends pas du tout :

pleiades david /usr/local/src/mozilla/obj-i686-pc-linux-gnu/intl/icu/target/data $ LD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:$LD_LIBRARY_PATH ../bin/genrb -k -R -i ./out/build/icudt52l -s /hugetmp/mozilla/intl/icu/source/data/coll -d ./out/build/icudt52l/coll root.txt
/hugetmp/mozilla/intl/icu/source/data/coll/root.txt:15: Collation could not be built- U_FILE_ACCESS_ERROR. Make sure ICU's data has been built and is loading properly.
/hugetmp/mozilla/intl/icu/source/data/coll/root.txt:15: parse error. Stopped parsing resource with U_FILE_ACCESS_ERROR
couldn't parse the file root.txt. Error:U_FILE_ACCESS_ERROR

Comme tout bon Unixien confronté à un comportement bizarre d'un programme qu'il ne connaît même pas, j'ai le réflexe strace. Et là, les choses deviennent encore plus mystérieuses :

pleiades david /usr/local/src/mozilla/obj-i686-pc-linux-gnu/intl/icu/target/data $ strace -f -o /tmp/dump -E LD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:$LD_LIBRARY_PATH ../bin/genrb -k -R -i ./out/build/icudt52l -s /hugetmp/mozilla/intl/icu/source/data/coll -d ./out/build/icudt52l/coll root.txt
strace: ../bin/genrb: command not found

Comment ça, command not found ? Je n'ai aucune idée de ce que le programme ../bin/genrb est censé faire, mais je suis sûr qu'il existe et qu'il s'exécute correctement. Pourquoi strace prétend-il ne pas pouvoir le trouver ?

Et pourquoi le fait d'avoir changé les disques durs de ma machine ferait-il échouer la compilation de Firefox ?

Je vous épargne la manière dont j'ai résolu le mystère (j'ai commencé par strace strace lui-même, qui ne m'a montré aucune erreur, ce qui rendait les choses encore plus incompréhensible, et j'ai fini par patcher le truc pour afficher la valeur de errno). Le secret était que la partition /hugetmp sur laquelle je compilais faisait plus de 2To, et que j'y avais mis un système de fichier XFS. Or pour les gros systèmes de fichiers, XFS utilise des numéros d'inodes de plus que 32-bits. Mon noyau est 64-bits, donc lui n'a pas de problème avec ça, mais sur cette machine j'ai un userland de 32-bits : dans ces conditions, tout dépend de si le programme a été compilé avec -D_FILE_OFFSET_BITS=64 ou non : si ce n'est pas le cas (ce qui, apparemment, vaut pour le strace de ma Debian comme pour le programme qui échouait en premier lieu), lorsque stat() est appelé sur un fichier et qu'un des champs de la structure de retour (typiquement, la taille, ou le numéro d'inode) dépasse le type 32-bits que la structure prévoit, alors la libc produit l'erreur EOVERFLOW (qui n'apparaît pas dans le strace du strace parce que ce n'est pas le noyau qui la renvoie, c'est la libc) ; et si on se contente de regarder si stat() a réussi ou pas, on a l'impression que le fichier n'existe pas ou qu'il y a une erreur d'accès.

Moralité :

  • Tous les programmes, sur un système 32-bits, devraient être compilés avec -D_FILE_OFFSET_BITS=64 (ou en tout cas, tous ceux qui utilisent stat(), c'est-à-dire, essentiellement, tous les programmes). Ne pas le faire va provoquer les erreurs les plus bizarres et inattendues. Même si on ne manipule pas des fichiers de plus de 2Go (qui sont la cause la plus courante de EOVERFLOW).
  • Si on veut utiliser des partitions XFS de plus de 1To sur un système qui risque de faire tourner des programmes 32-bits, on a intérêt à augmenter la taille des inodes (passer à 512 bits à partir de 1To, à 1024 bits à partir de 2To, etc. ; au-delà de 8To, on ne peut plus s'en sortir). Ce n'est pas très satisfaisant, cela fera perdre de la place, mais à moins de vouloir résoudre les bugs (i.e., la non-application du premier point) de la moitié de la distribution, il faudra bien faire un choix.

Noter que contrairement à ce que prétend la doc (if no inode size is given on the command line, mkfs.xfs will attempt to choose a size such that inode numbers will be < 32 bits. If an inode size is specified, or if a filesystem is sufficently large, mkfs.xfs will warn if this will create inode numbers > 32 significant bits), mkfs.xfs n'a, lorsque j'ai créé le système de fichiers, ni choisi une taille d'inode suffisante pour rester avec des numéros d'inode de 32-bits, ni affiché d'avertissement.

↑Entry #2221 [older| permalink|newer] / ↑Entrée #2221 [précédente| permalien|suivante] ↑

↓Entry #2220 [older| permalink|newer] / ↓Entrée #2220 [précédente| permalien|suivante] ↓

(lundi)

Les disques durs se cachent pour mourir

Je ne vais pas commencer à raconter tout le temps que j'ai perdu cet été avec mes ordinateurs : entre mon père qui a décidé de déménager plein de choses dans son sous-sol et qui a branché l'alimentation du disque dur externe de la machine servant de routeur sur un transformateur délivrant la mauvaise tension, et un ordinateur hébergé à l'ENS qui a été déconnecté sans aucun avertissement et qui m'a valu quantité de mails pour expliquer la situation aux utilisateurs, rien que raconter les choses prendrait plus de temps que je n'en ai.

La dernière péripétie est que deux des trois disques durs du PC que j'ai chez mes parents (et qui me sert notamment de stockage de sauvegardes) ont décidé de mourir simultanément, et, qui plus est, pendant que j'étais en vacances en Allemagne. L'un (un Maxtor DiamondMax® STM3750330AS de 750Go, acheté en avril 2008 et utilisé seulement depuis novembre 2011, nommé sdc ou ata2.01 dans les logs qui suivent) a brutalement cessé purement et simplement de répondre à la moindre commande :

Sep  1 22:37:43 pleiades kernel: [1749716.736036] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep  1 22:37:43 pleiades kernel: [1749716.736044] ata2.01: failed command: SMART
Sep  1 22:37:43 pleiades kernel: [1749716.736050] ata2.01: cmd b0/da:00:00:4f:c2/00:00:00:00:00/10 tag 0
Sep  1 22:37:43 pleiades kernel: [1749716.736050]          res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Sep  1 22:37:43 pleiades kernel: [1749716.736054] ata2.01: status: { DRDY }
Sep  1 22:37:48 pleiades kernel: [1749721.785014] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749724.182021] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749731.416141] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades kernel: [1749731.416149] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749731.416153] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749736.312020] ata2: soft resetting link
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, not capable of SMART self-check 
Sep  1 22:39:47 pleiades kernel: [1749736.482563] ata2.01: configured for UDMA/133
Sep  1 22:39:47 pleiades kernel: [1749736.482584] ata2: EH complete
Sep  1 22:39:47 pleiades kernel: [1749746.720034] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep  1 22:39:47 pleiades kernel: [1749746.720043] ata2.01: failed command: SMART
Sep  1 22:39:47 pleiades kernel: [1749746.720050] ata2.01: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/10 tag 0 pio 512 in
Sep  1 22:39:47 pleiades kernel: [1749746.720050]          res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Sep  1 22:39:47 pleiades kernel: [1749746.720054] ata2.01: status: { DRDY }
Sep  1 22:39:47 pleiades kernel: [1749751.769022] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749756.767014] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749756.767023] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749764.011135] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades kernel: [1749764.011140] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749764.011144] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749769.060013] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749774.058012] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749774.058019] ata2: soft resetting link
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, failed to read SMART Attribute Data 
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, Read SMART Self Test Log Failed 
Sep  1 22:39:47 pleiades kernel: [1749786.302021] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades kernel: [1749786.302026] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749786.302029] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749791.351016] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749796.349013] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749796.349024] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749828.593026] ata2.01: qc timeout (cmd 0xec)
Sep  1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, Read Summary SMART Error Log failed 
Sep  1 22:39:47 pleiades kernel: [1749828.593035] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep  1 22:39:47 pleiades kernel: [1749828.593039] ata2.01: revalidation failed (errno=-5)
Sep  1 22:39:47 pleiades kernel: [1749828.593042] ata2.01: disabled
Sep  1 22:39:47 pleiades kernel: [1749833.642016] ata2: link is slow to respond, please be patient (ready=0)
Sep  1 22:39:47 pleiades kernel: [1749838.640016] ata2: device not ready (errno=-16), forcing hardreset
Sep  1 22:39:47 pleiades kernel: [1749838.640028] ata2: soft resetting link
Sep  1 22:39:47 pleiades kernel: [1749840.841810] ata2: EH complete
Sep  1 22:39:47 pleiades kernel: [1749840.842031] end_request: I/O error, dev sdc, sector 15438448
Sep  1 22:39:47 pleiades kernel: [1749840.842036] md: super_written gets error=-5, uptodate=0
Sep  1 22:39:47 pleiades kernel: [1749840.842041] md/raid1:md2: Disk failure on sdc5, disabling device.
Sep  1 22:39:47 pleiades kernel: [1749840.842041] md/raid1:md2: Operation continuing on 2 devices.
Sep  1 22:39:47 pleiades kernel: [1749840.842206] sd 1:0:1:0: [sdc] Asking for cache data failed
Sep  1 22:39:47 pleiades kernel: [1749840.842213] sd 1:0:1:0: [sdc] Assuming drive cache: write through

— tandis que l'autre (un Western Digital Caviar Blue® WD10EALX-009BA0 de 1To, acheté en juin 2012, et nommé sdb ou ata1.01 dans les logs qui suivent) n'a pas tardé à se découvrir quantité de secteurs défectueux :

Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, FAILED SMART self-check. BACK UP DATA NOW! 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Prefailure Attribute: 3 Spin_Up_Time changed from 176 to 187 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, Failed SMART usage Attribute: 5 Reallocated_Sector_Ct. 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 200 to 42 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 7 Seek_Error_Rate changed from 200 to 21 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 107 to 108 
Sep  2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 196 Reallocated_Event_Count changed from 200 to 84 

(Qu'on se rassure, malgré le message trompeur, il n'était pas vraiment à 108°C : le 108 est une valeur normalisée SMART, qui pour ce fabricant semble correspondre à environ 40°C.) Ce disque a continué à plus ou moins fonctionner (mais lentement, en faisant des bruits bizarres, et de rares vraies erreurs), au moins le temps de me permettre d'en récupérer en catastrophe celles de mes données qui n'étaient protégées que contre l'échec d'un seul disque.

Je ne peux pas vraiment dire que je sois passé près de la catastrophe : en vérité, non seulement comme je viens de le dire le disque mourant a tenu le coup le temps que j'en extraie tout ce que je voulais extraire, mais de toute façon les données vraiment importantes étaient en redondance triple (RAID1 sur les trois disques), et même ces données étaient essentiellement des sauvegardes incrémentales de données qui sont en redondance au moins quintuple sur des ordinateurs à deux endroits physiquement séparés (sans compter des sauvegardes sur médias optiques) — bref, je suis passablement parano avec la perte d'information. Néanmoins, j'aurais pu perdre quelques choses qui m'auraient agacé, et beaucoup plus de temps que je n'en ai déjà passé à racheter des nouveaux disques et recopier tout ce que j'avais sur ceux-ci (ce qui, quand le disque dur mourant descend jusqu'à 3Mo/s et qu'on a 750Go à copier, prend… longtemps). J'ai donc augmenté ma paranoïa d'encore un cran et mis encore plus de partitions en redondance triple : après tout, ça ne sert à rien d'économiser vingt gigas par-ci par-là quand j'en ai des centaines dont je ne me sers pas vraiment.

Mais au-delà de cette non-catastrophe, la question demeure de savoir comment il se fait que deux disques durs aient pu mourir en même temps (et cette question a de l'importance, parce que si deux peuvent, alors trois peuvent aussi, et je ne serais vraiment vraiment pas content). J'avais déjà eu une expérience de ce genre qui s'était avérée n'être qu'une vapeur du contrôleur, mais cette fois les disques ont bien l'air d'être endomagés. Il n'y a pas eu d'orage à cette période qui expliquerait, par exemple, une surtension électrique. Je peux vaguement soupçonner soit une insuffisance de l'alimentation ou une chaleur excessive, mais aucune de ces hypothèses n'est corroborée par un indice tangible. Par ailleurs, les deux disques ont commencé à défaillir à presque exactement 24h d'intervalle, ce qui est peut-être significatif, mais je ne sais pas de quoi (il n'est rien censé se passer de particulier à ce moment-là).

J'ai racheté (à Hambourg) trois nouveaux disques durs, en essayant de trouver trois constructeurs différents, mais comme je le soupçonnais c'est une tâche impossible : je ne sais pas exactement combien existent de chaînes vraiment indépendantes de fabrication de disques durs, mais le nombre de marques semble être tombé à 2 (Seagate ayant, je crois, acquis Maxtor ; et Western Digital), comme par hasard ceux qui m'ont empiriquement posé le plus de problèmes par le passé (alors que Hitachi, Samsung et IBM, qui semblaient considérablement plus fiables, soient ne fabriquent plus de disques, soit au moins ont cessé de les revendre aux péquenots comme moi).

Je constate aussi de nouveau ce que j'avais déjà cru détecter, à savoir que (dans des mesures raisonnables) plus un disque dur est ancien, plus il est fiable : ce sont mes disques les plus récents qui ont lâché (pour référence, celui qui continuait à fonctionner était un Samsung SpinPoint® HD501LJ de 500Go, acheté en novembre 2007). Autrement dit, il me semble que sur un disque dur, le phénomène d'usure avec le temps est beaucoup moins important que le phénomène de défaut caché à la fabrication (appelé aussi mortalité infantile des disques durs) et que l'expérience permet de dévoiler : plus votre disque a tenu longtemps, plus il y a des chances qu'il soit de bonne qualité et continue à tenir longtemps. Il est vrai que les deux disques dont on parle étaient tous trop vieux pour vraiment entrer dans la case « mortalité infantile », donc c'est peut-être simplement une coïncidence.

Bien sûr, mes observations aussi bien sur la fiabilité relative des marques que sur la fiabilité avec le temps sont basées sur des données statistiquement insuffisantes, et même pas collectées de façon systématique. Ceux qui pourraient le mieux fournir des informations vraiment scientifiques sur la fiabilité des disques, c'est Google : malheureusement, une étude qu'ils ont publiée il y a quelque temps à ce sujet ne veut rien révéler sur les marques de disques durs plus ou moins fiables. À défaut, j'ai trouvé deux rapports de la compagnie de stockage Blackblaze, celle-ci sur la durée de vie des disques durs en général et celle-là sur les marques plus ou moins fiables, qui corroborent au moins partiellement mes impressions (les disques durs jeunes ont le plus tendance à mourir, le minimum du taux de mortalité se situant d'après eux vers 2 ans d'âge ; et Hitachi semble bien la marque la plus fiable — ou du moins semblait). Il faut néanmoins bien prendre note que les conditions d'utilisation (température, pourcentage du temps passé allumé, nombre de cycles de garage des têtes, etc.) peuvent changer du tout au tout les résultats de ce genre de mesures, donc on reste dans le domaine de la boule de cristal.

↑Entry #2220 [older| permalink|newer] / ↑Entrée #2220 [précédente| permalien|suivante] ↑

Continue to older entries. / Continuer à lire les entrées plus anciennes.


Entries by month / Entrées par mois:

2024 Jan 2024 Feb 2024 Mar 2024
2023 Jan 2023 Feb 2023 Mar 2023 Apr 2023 May 2023 Jun 2023 Jul 2023 Aug 2023 Sep 2023 Oct 2023 Nov 2023 Dec 2023
2022 Jan 2022 Feb 2022 Mar 2022 Apr 2022 May 2022 Jun 2022 Jul 2022 Aug 2022 Sep 2022 Oct 2022 Nov 2022 Dec 2022
2021 Jan 2021 Feb 2021 Mar 2021 Apr 2021 May 2021 Jun 2021 Jul 2021 Aug 2021 Sep 2021 Oct 2021 Nov 2021 Dec 2021
2020 Jan 2020 Feb 2020 Mar 2020 Apr 2020 May 2020 Jun 2020 Jul 2020 Aug 2020 Sep 2020 Oct 2020 Nov 2020 Dec 2020
2019 Jan 2019 Feb 2019 Mar 2019 Apr 2019 May 2019 Jun 2019 Jul 2019 Aug 2019 Sep 2019 Oct 2019 Nov 2019 Dec 2019
2018 Jan 2018 Feb 2018 Mar 2018 Apr 2018 May 2018 Jun 2018 Jul 2018 Aug 2018 Sep 2018 Oct 2018 Nov 2018 Dec 2018
2017 Jan 2017 Feb 2017 Mar 2017 Apr 2017 May 2017 Jun 2017 Jul 2017 Aug 2017 Sep 2017 Oct 2017 Nov 2017 Dec 2017
2016 Jan 2016 Feb 2016 Mar 2016 Apr 2016 May 2016 Jun 2016 Jul 2016 Aug 2016 Sep 2016 Oct 2016 Nov 2016 Dec 2016
2015 Jan 2015 Feb 2015 Mar 2015 Apr 2015 May 2015 Jun 2015 Jul 2015 Aug 2015 Sep 2015 Oct 2015 Nov 2015 Dec 2015
2014 Jan 2014 Feb 2014 Mar 2014 Apr 2014 May 2014 Jun 2014 Jul 2014 Aug 2014 Sep 2014 Oct 2014 Nov 2014 Dec 2014
2013 Jan 2013 Feb 2013 Mar 2013 Apr 2013 May 2013 Jun 2013 Jul 2013 Aug 2013 Sep 2013 Oct 2013 Nov 2013 Dec 2013
2012 Jan 2012 Feb 2012 Mar 2012 Apr 2012 May 2012 Jun 2012 Jul 2012 Aug 2012 Sep 2012 Oct 2012 Nov 2012 Dec 2012
2011 Jan 2011 Feb 2011 Mar 2011 Apr 2011 May 2011 Jun 2011 Jul 2011 Aug 2011 Sep 2011 Oct 2011 Nov 2011 Dec 2011
2010 Jan 2010 Feb 2010 Mar 2010 Apr 2010 May 2010 Jun 2010 Jul 2010 Aug 2010 Sep 2010 Oct 2010 Nov 2010 Dec 2010
2009 Jan 2009 Feb 2009 Mar 2009 Apr 2009 May 2009 Jun 2009 Jul 2009 Aug 2009 Sep 2009 Oct 2009 Nov 2009 Dec 2009
2008 Jan 2008 Feb 2008 Mar 2008 Apr 2008 May 2008 Jun 2008 Jul 2008 Aug 2008 Sep 2008 Oct 2008 Nov 2008 Dec 2008
2007 Jan 2007 Feb 2007 Mar 2007 Apr 2007 May 2007 Jun 2007 Jul 2007 Aug 2007 Sep 2007 Oct 2007 Nov 2007 Dec 2007
2006 Jan 2006 Feb 2006 Mar 2006 Apr 2006 May 2006 Jun 2006 Jul 2006 Aug 2006 Sep 2006 Oct 2006 Nov 2006 Dec 2006
2005 Jan 2005 Feb 2005 Mar 2005 Apr 2005 May 2005 Jun 2005 Jul 2005 Aug 2005 Sep 2005 Oct 2005 Nov 2005 Dec 2005
2004 Jan 2004 Feb 2004 Mar 2004 Apr 2004 May 2004 Jun 2004 Jul 2004 Aug 2004 Sep 2004 Oct 2004 Nov 2004 Dec 2004
2003 May 2003 Jun 2003 Jul 2003 Aug 2003 Sep 2003 Oct 2003 Nov 2003 Dec 2003

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]