DigitalSpirit / Blog

Offre remboursement Sfr Illymitics / Parrot Party

Fin décembre / début janvier, je décidais de quitter Orange appaté par l'offre Sfr Illymitics / Nokia N95 à un prix fort intéressant.
Un remboursement de 100€ devait avoir lieu quelques temps après sous la forme d'un virement.

Je décidais également de souscrire à une offre qui me paraissait elle aussi intéressante puisqu'elle me proposait un remboursement de 99€ sur un kit bluetooth Parrot Party.
Je repartais donc de la boutique Sfr avec mon N95 flambant neuf, mon nouvel abonnement Sfr et mes enceintes Parrot Party.

Le 31 mars 2008, toujours aucun remboursement, ni de Sfr, ni de l'offre Parrot Party, je décidais donc d'appeler pour savoir oû en était l'opération, je vous passe les détails sur l'obtention du bon numéro de téléphone et les aller retour téléphonique avec la boutique Sfr, bref, je finissais par avoir quelqu'un s'occupant de l'ODR (Offre De Remoursement) Sfr qui m'apprenait que le virement avait été refusé.
Après quelques recherches de leur part, il s'avérait que le RIB n'était pas le bon (alors que j'ai détaché un RIB de mon carnet de chèque), bref, on m'indiquait que je recevrais un chèque d'ici une quinzaine de jours.

Même discours chez la structure gérant l'ODR Parrot Party, virement refusé, le RIB n'est pas bon, je redonne de nouveau mon RIB et on m'annonce qu'on me fera un virement mi mai.

15 jours plus tard, je reçois un chèque de 100€ concernant l'ODR Sfr, le premier dossier est clos.

Nous sommes maintenant le 30 mai et toujours aucune nouvelle de l'ODR Parrot Party, je décide donc d'appeler, je suis accueilli très très froidement, apparemment, la personne n'a pas vraiment envie de travailler, bref, je lui explique que je n'ai toujours pas de remboursement alors qu'il était prévu mi mai, les esprits s'échauffent quelque peu car la personne ne comprend pas que ça fait 6 mois que j'attends et que j'en ai marre de payer des numéros surtaxés, finalement, elle me dit qu'on me rappelera, je n'ai pas vraiment le choix.

15 minutes plus tard, je suis contacté, on me dit que le virement à été fait le 28 mars et qu'il faut vérifier avant de déranger les gens (référence à mon précédent coup de fil), pris d'un doute affreux, je consulte directement mes relevés de comptes : aucun virement de 99€, le ton monte alors encore un peu, finalement, mon interlocutrice va se renseigner et me rappelera.

Encore 15 minutes plus tard, on me rappelle, le ton à clairement changé, apparemment, ils se sont aperçu de leur erreur, je leur demande le numéro d'opération du précédent virement comme me l'a conseillé un collègue, elle esquive brillamment la question en changeant immédiatement de sujet, bref, elle me dit que le virement aura lieu aujourd'hui même...

Voilà, nous sommes le 30 mai 2008 et sauf, nouveau rebondissement, je vais être remboursé des 99€ d'un produit acheté fin décembre 2007, c'est lamentable.

Pour en revenir sur le problème originel, on me dit que le RIB n'est pas le bon, à cela, je vois plusieurs raisons possible :

  • Une erreur de ma part, j'aurai donc glisser le RIB d'un chèque ne m'appartenant pas : plutôt ridicule
  • Une erreur de saisie du RIB : j'ai beaucoup de mal à le croire car la clef RIB est là pour éviter ce genre d'erreur
  • Une erreur volontaire : ?

Je trouve ça tout simplement scandaleux qu'on ne tente pas de contacter le client lorsqu'une erreur de la sorte se produit, le virement ne passe pas, on cherche d'oû vient l'erreur, et on essaie de faire en sorte que ça fonctionne mais non, on s'en fou du client, on a pas envie de perdre son temps à résoudre un problème qui ne nous concerne pas.

Et enfin, pour finir, contrairement à ce que mon insinué mes interlocuteurs au téléphone, je ne suis pas un cas isolé :

Ouvrir l'article

Onglets dans la même instance de GVim

Voilà une petite astuce pour les utilisateurs de GVim qui vous permettra d'ouvrir tous vos documents dans la même instance grâce aux onglets.

La page Vim documentation : remote nous apprend qu'il est possible de faire fonctionner Vim comme un serveur recevant des messages de clients et exécutant les commandes demandées par ces derniers.
Une de ces commandes nous intéresse et va justement nous permettre d'ouvrir des documents dans la même instance de Vim, il s'agit de remote-tab-silent.

Testons cette commande :

 $ gvim -p --remote-tab-silent toto

Une instance de GVim s'ouvre avec toto dans un onglet (le paramètre p permet d'ouvrir un onglet par fichier).
Gardons GVim ouvert et testons de nouveau :

 $ gvim -p --remote-tab-silent foo

Le fichier foo s'affiche maintenant dans un nouvel onglet de la même instance GVim, nous avons donc 2 fichiers ouvert dans GVim : toto et foo.

J'ai fait un petit script bash qui permet de s'affranchir des problèmes rencontrés à l'ouverture avec Nautilus (qui tente d'ouvrir les documents avec le paramètre "-f") et qui évite surtout de devoir saisir les paramètres à chaque fois, il suffit alors de remplacer le fichier binaire de gvim par le script :

 $ mv /usr/bin/gvim /usr/bin/gvim-bin

Ensuite, il vous suffit de déposer le script ci joint dans le dossier /usr/bin et de lui attribuer les droits d'exécution.

Bon Gvim !

Ouvrir l'article

Nouvelles du projet de gestionnaire de fichiers Hyla

Voilà maintenant quelques temps que Hyla ne fait pas parler beaucoup de lui, néanmoins, voici quelques nouvelles :

  • Le site officiel de Hyla à déménagé de notre ancien hébergeur (TuxFamily, je tiens d'ailleurs à remercier toute l'équipe de Tuxfamily pour le travail), ce changement permettra d'avoir un peu plus de souplesse sur la gestion du site.
  • Un blog consacré à Hyla à ouvert récemment et vous permettra de suivre l'activité du développement, ce dernier fonctionne grâce à DotClear.
  • Une interface de gestion des bugs à également ouvert et permet de saisir / voir la liste des bugs, de voir l'avancement général et tout plein d'autres choses, bref, un super outils de développeur propulsé par Trac
Voilà, maintenant, en route pour la nouvelle version !!

Ouvrir l'article

Les opérateurs de recherche dans Google

Logo de Google

Voici une liste non exhaustive des mots clefs reconnu par Google lors de recherche, ces mots clefs peuvent être précédé du signe moins ( - ) afin d'exclure des résultats des termes :

  1. site Lance une recherche sur un site en particulier
    L'exemple suivant va exécuter une recherche du terme "eeepc" sur le site www.digitalspirit.org
    site:www.digitalspirit.org eeepc
  2. inurl (allinurl) Renvoie toutes les pages contenant le mot clef dans l'url
    inurl:bluetooth
  3. intitle (allintitle) Renvoie les pages dont la balise "title" contient le mot clef
    L'exemple suivant affiche les pages contenant le terme linux OU gentoo
    intitle:"linux gentoo"
    Cherche les pages contenant le terme linux ET gentoo
    allintitle:"linux gentoo"
  4. intext (allintext) Comme on pourrait le penser, cet opérateur effectue une recherche uniquement dans le texte
  5. inanchor (allinanchor) Lance une recherche dans les balises "a" (anchor), c'est à dire dans les liens des pages (pas dans l'attribut href mais bien dans le contenu de la balise a)
  6. filetype (alias ext) Exécute une recherche avec en critère le format de fichier voulu (voir plus bas pour la liste des formats supportés)
    L'exemple suivant va renvoyer les documents pdf contenant le terme "sd specification"
    filetype:pdf "sd specification"
  7. link Renvoie tous les sites ayant un ou des liens pointant vers le site concerné
    link:www.linuxfr.org
  8. related Permet d'obtenir les pages similaires au site spécifié
    L'exemple est assez parlant :
    related:google.com
  9. info Renvoie les informations sur la page et des liens directs utiles (related, site, cache...etc)
    info:www.wikipedia.fr
  10. define Vous permet d'obtenir une définition du terme recherché
    define:gnu/linux
  11. cache Obtenir la page du cache si elle est disponible
    cache:/
  12. movie Fait une recherche sur le film voulu et affiche des critiques, les salles...
    movie:"forrest gump"
  13. stocks Renvoie les informations concernant une société (notation abrégée boursière)
    stocks:goog

Les opérateurs entre paranthèses (allintitle, allintext...) permettent de renvoyer les pages possédant TOUS les mots clefs spécifiés, notons que cette opérateur est à utilisé seul dans la requête.

Exemples de recherches combinées :

Voici quelques formats, notez que le champs de recherches n'est pas limité à cette liste, en fait, Google indexe toutes les extensions ainsi, vous pouvez très bien faire une recherche du type filetype:monextension et Google vous trouvera tous les fichiers ayant comme extension "monextension" :

  • Adobe Portable Document Format : pdf
  • Adobe Postscript : eps, ps
  • Autodesk : dwf
  • Google Earth : klm, kmz
  • Microsoft Access : mdb
  • Microsoft Excel : xls
  • Microsoft Word : doc
  • Microsoft PowerPoint : ppt
  • Rich Text Format : rtf
  • Shockwave Flash : swf

Pour en savoir plus, je vous conseille un tour sur Google Guide.

Ouvrir l'article

Mémoire Flash et aimant font-ils bon ménage ?

Je me baladais dans une grande surface informatique lorsque j'ai entendu un vendeur raconter, sûr de lui, que la proximité d'un aimant et d'une mémoire flash aurait des conséquences dramatiques pour cette dernière, à savoir une perte de données irrémédiable.

Quelques temps auparavant m'était justement arrivé cette mésaventure, je cherchais ma clef usb que j'avais fini par retrouver collée...à un aimant et cela, sans le moindre dégâts sur les données.

Je repartis du magasin en me disant qu'il serait bon de savoir si, oui ou non, les aimants étaient dangereux pour nos précieuses données contenues dans des mémoires flash, en théorie non, mais à force d'entendre cette légende, j'ai pensé qu'il serait bon de tester, c'est le but de cet article...

Procédure de test

Afin de vérifier le danger ou non d'un aimant à côté d'une mémoire de type Flash, nous allons mettre un aimant à proximité immédiate d'une carte Flash pendant des durées croissantes en contrôlant à chaque étape l'intégrité des données.

Les protagonistes sont les suivants, tout d'abord, les cartes mémoires :

flash.jpg

Deux aimants « collés » l'un sur l'autre, petits mais costauds, je n'ai pas mesuré l'intensité de ces aimants mais pour essayer de vous donner une idée, je peux vous dire qu'il est très dur, voir impossible, de les séparer à la force des mains une fois l'un sur l'autre...

flash_magnet.jpg

Pour s'assurer de l'état des données après chaque phase de test, une lecture sera faite dans la carte et une comparaison de md5 sera faite sur l'intégralité de la carte.

Afin d'avoir un rendu plus lisible, le contenu de la carte sera une image au format TGA et c'est Léonard de Vinci qui nous prêtera son auto-portrait, la détérioration du contenu altérera visiblement l'image ainsi, il sera possible, en cas de détérioration de la mémoire flash, de voir visuellement les zones abimées.

Pour simplifier les tests, j'ai créé 2 scripts :

  • fl_create_ref : Créer les fichiers de référence
    Liste des arguments :
    • d : Le périphérique (ex: -d /dev/sda1)
    • f : Identifiant de la flash (voir les numéros collés sur les clefs)

    Le script exécute les actions suivantes :

    1. Charge les données de l'image (sans l'en-tête) dans le périphérique
    2. Dumpe la mémoire flash du périphérique et stocke le contenu dans un fichier, ce dernier servira de référence
    3. Calcule le Md5 de la référence
  • fl_test : Exécute un test du périphérique
    Liste des arguments :
    • d : Le périphérique (ex: -d /dev/sda1)
    • f : Identifiant de la flash (voir les numéros collés sur les clefs)
    • s : Étape (step), c'est à dire, le premier test, le second, etc...
    Ce script va se contenter de lire la mémoire flash, stocker le dump, calculer la somme Md5 et finalement exécuter une comparaison entre la référence de la mémoire courante et le dump obtenu.

Test

leonardo.jpg

Tout d'abord, il faut remplir les mémoires et créer les références pour chaque périphérique, cela est fait grâce au script fl_create_ref :

./fl_create -d /dev/xxx -f 1
./fl_create -d /dev/yyy -f 2
./fl_create -d /dev/zzz -f 3

Une fois cette étape effectuée, il faut mettre à l'épreuve les mémoires, pour cela, j'ai mis en contact direct l'aimant avec la puce durant un temps déterminé.

Voici les différentes étapes durant lesquelles les mémoires flash ont été en contact direct avec l'aimant :

  1. 10 min
  2. 3 h
  3. 13 h
  4. 240 h

À la fin de chaque test, j'ai utilisé le script fl_test de cette manière :

./fl_test -d /dev/xxx -f 1 -s 2

Le paramètre -s correspondant bien sûr au numéro de l'étape (1 pour 10min, 3 pour 3h...)
Ainsi, à chaque étape, nous avons un dump complet pour chaque mémoire ainsi que les sommes Md5 associées.

Voici l'arborescence des fichiers une fois tous les tests réalisés :

$ tree
|-- README
|-- fl_create_ref
|-- fl_test
|-- flash
|-- 1
| |-- leonard.data
| |-- leonard.md5
| |-- log
| |-- out-1.dump
| |-- out-2.dump
| |-- out-3.dump
| `-- out-4.dump
|-- 2
| |-- leonard.data
| |-- leonard.md5
| |-- log
| |-- out-1.dump
| |-- out-2.dump
| |-- out-3.dump
| `-- out-4.dump
|-- 3
| |-- leonard.data
| |-- leonard.md5
| |-- log
| |-- out-1.dump
| |-- out-2.dump
| |-- out-3.dump
| `-- out-4.dump
`-- log

C'est donc avec l'oeil averti de Léonard que les tests se sont succédés.

Résultats

Les résultats sont clairs, nets et précis, l'aimant (immobile) placé à proximité immédiate des mémoires flash n'a en rien altéré les données présentes dans les puces.
Les sommes Md5 sont restés invariables et cela, aussi bien pour 10 minutes que pour 10 jours.

L'aimant n'a donc pas réussi à faire broncher le regard de Léonard...Rien de vraiment étonnant en considérant le fonctionnement interne d'une mémoire flash, l'étape suivante serait donc de tester les mémoires flash à proximité de champs magnétiques fluctuants (moteurs, antennes d'émissions...)

Annexe

Vous trouverez en pièces jointes une archive contenant les scripts décrits ci-dessus et les fichiers images qui ont été mis dans les mémoires.

Ouvrir l'article

« Page 20 / 32 »