Blog Jaune

Cheminée ferry

Antoine — Mon, 16 Aug 2010 10:57:17 -0000

Cette photo date de l'année dernière. Mais je l'aime bien quand même :o

PhotoFacade

Antoine — Mon, 16 Aug 2010 09:54:26 -0000

Héhé©

Artifices à Calvi

Antoine — Mon, 16 Aug 2010 09:03:27 -0000

La photo de Calvi est une étape obligatoire de chaque été sur ce blog :-)

Mac OS X n'est pas près pour les ordinateurs de bureau

Antoine — Thu, 12 Aug 2010 15:57:26 -0000

Dans la lignée des journaux du vendredi qui ne servent à rien, mais qui parlent quand même d'informatique, ce journal va vous expliquer pourquoi mac os x n'est pas près pour les ordinateurs de bureau. Si vous avez quelque chose de mieux à faire que de lire ce journal, faites quelque chose de mieux.

Pour commencer, je tiens à dire que ce journal a été écris sur mac os x 10.5, qui n'est pas la dernière version du système d'exploitation d'apple, puisque cette entreprise a jugé bon de ne plus supporter l'architecture power pc. Chez debian ils en ont 42, mais chez apple, gérer deux architectures en même temps, c'est trop de travail, et ça fait chier les actionnaires.

Premier exemple :
Ce matin, plutôt de bonne humeur et faisant les préparatifs pour partir en vacances, je pense à créer une session invité sur mon fixe, histoire qu'il s'amuse lui aussi avec les invités.

Ça c'est facile, un petit clic, et c'est terminé. Je regarde le résultat, histoire de voir si cela fonctionne. Je tombe donc sur la fenêtre de connexion de mac os x, équivalent de GDM ou KDM.

Bon, pour ne pas faciliter les choses, j'utilise un clavier bépo, avec les touches dans l'ordre bépo. Mais la fenêtre de connexion demande une saisie en azerty… Et aucun moyen de changer l'ordre des touches du clavier, pourtant GDM sais le faire. Ne sachant pas taper en azerty sans un repaire visuel de départ, je suis dans l'impossibilité de me connecter avec mon compte.

Je me connecte donc en invité, ce qui ne demande pas de mot de passe. Je choisis le clavier bépo dans la liste des layouts. Pour information, on change de clavier dans «International» sur mac os x, et pas dans «Clavier et Souris».

Je désactive donc le compte invité et remet la connexion automatique sur mon compte utilisateur. Quand on utilise pas un clavier azerty, la fenêtre de connexion est inutilisable. Donc pas de compte invité sur mon mac.

Deuxième exemple :
J'ai besoin de scanner des documents, et j'ai pour cela un vieux scanner qui traîne. Je sais qu'il a fonctionné sur windows 98, et mac os 9.1, ça date donc, même si le modèle possède une prise usb.
Je le branche sur mon mac, et aucune réaction. «Aucun périphérique d'acquisition d'image n'est détecté». Je le branche sur mon ultra portable ubuntu (vendu avec ubuntu), et je lance le truc de gnome pour scanner. Du premier coup, et sans attendre, il se remet en marche, et fonctionne parfaitement.

Bon, je remarque qu'il est lent, et qu'en plus la vitre est tachée du mauvais cotés. Ayant la flemme de le démonter, je me décide à déplacer une imprimante/scanner récente, et à la brancher sur mon mac. Là encore, aucune réaction. Je la branche encore une fois sur mon ordinateur avec ubuntu, et cela fonctionne du premier coup. C'est magique.

Donc les scanner et mac os x, c'est plus ce que c'était.

Troisième exemple :
On a longtemps pris pour exemple la gestion de la mise en veille de mac os x. Très rapide et très efficace. Et bien je peut vous assurer que mes ordinateurs ayant Linux sortent de veille bien plus vite que ceux sous mac os x. Mis à part le fait que le mac triche après au niveau du réseau en ne demandant pas de nouvelle adresse en dhcp…

Pareil pour le temps de démarrage. Une distribution comme Debian ou Ubuntu démarre bien plus vite que mac os x, alors que ce dernier a longtemps été réputé pour son temps de démarrage.

Tout ça pour dire que par rapport aux distribution GNU/Linux classiques, mac os x a encore de nombreux progrès à faire pour les ordinateurs de bureau.

iPapy grand frère, pour le bien de l'économie

Antoine — Thu, 12 Aug 2010 15:55:40 -0000

Le degré de confiance que j'accorde à la source est relativement faible, mais le sujet est tellement sensible que laisser passer l'information serais dommage.

Il semblerait que les iPhones envoient le trajet GPS quotidien des utilisateurs à Apple.

Mais, ce n'est actuellement qu'aux états-unis, ce qui empêche de confirmer l'information par des amis ayant l'engin…

Évidemment, Apple annonce que c'est anonymisé, que c'est écrit dans les conditions d'utilisation de l'appareil, et que de toutes façon, il n'y a pas à se faire de soucis, ils sont les seuls à utiliser l'information.

Ces parcours seraient à mettre en corrélation avec le service de publicités de la grande firme.

Effectivement, quoi de plus beau que de proposer sur une belle carte d'une grande ville, les trajets les plus fréquents des utilisateurs, et vendre les emplacements de pubs.

L'iPhone était l'appareil le plus privateur au monde. Il devient la plus triste invention humaine après les armes de guerres.

Il y a des jours où j'ai envi de créer un collectif qui lute contre l'iPhone… Car en plus, personne n'en a rien à foutre.

Source : http://www.numerama.com/magazine/16389-les-trajets-des-utili(...)

Chromium

Antoine — Thu, 12 Aug 2010 15:53:40 -0000

Première partie :

Alors que je suis dans le train en train de développer une jolie feuille de style pour un site web, je remarque que Chromium est un espion à la solde des méchants.

En effet, je développe en local avec un serveur web local, ce qui ne demande pas de connexion internet. Ce qui tombe bien, puisque je suis dans un train.

La première surprise arrive quand l'on tape localhost dans Chromium, il fait une recherche de localhost sur google… Pour ceux qui ne le savent pas, localhost est un nom correspondant à l'adresse locale de l'ordinateur. C'est la première chose que l'on utilise quand on commence la programmation réseau. Bon, une fois que l'on fait bien attention à taper http://localhost/, on peut visiter son site en local.

Mais cette fois là, il me répond que le réseau est indisponible pour accéder à localhost… Le détail de l'erreur explique que le nom n'a pas pu être résolu. Faute de serveur de noms à disposition certainement. Cela peut faire penser que Chromium ne connait pas le fichier /etc/hosts, qui est prioritaire sur n'importe quel serveur de nom, surtout quand ils sont injoignables.

Mais je décide alors d'écrire directement l'adresse ip, pour ne pas utiliser de serveur de nom, puisque ce navigateur est trop con. Je tape alors http://127.0.0.1/ l'adresse qui renvoi vers la boucle local, et qui est celle correspondant au nom localhost, comme décrit dans le fichier /etc/hosts . Et là, c'est assez intéressant, puisque j'obtiens exactement la même erreur. Le nom n'a pas été résolu, puisque le serveur de nom est introuvable.

À ce stade, il y a trois possibilités qui s' envisagent selon moi. Il est tout simplement possible que les développeurs de google aient réécris des librairies de bas niveau, et qu'étant très mauvais, ils font des requêtes DNS même pour les adresses ip. Ce serait étrange venant d'une équipe qui a écrit un navigateur web si performant en réécrivant certains composants…

Une autre possibilité est que c'est totalement volontaire de faire des requêtes dns pour une adresse ip, et que le but serait de connaître sur quels sites l'on visite, même quand c'est à partir de l'adresse ip. Ce serais à relier avec leur service DNS à l'adresse ip si simple à retenir : 8.8.8.8 . Mais il ne faut pas voir le mal partout, et cette possibilité serais aussi étrange, je ne vois pas trop ce qu'ils peuvent en tirer, à part la possibilité de censurer une adresse ip.

La dernière possibilité est que le navigateur souhaite communiquer avec un autre serveur à chaque visite d'une page, et que ce serveur soit identifié à l'aide d'un nom de domaine. Mais ce serais très étrange, car un coup de wireshark suffirait pour remarquer des échanges anormaux avec des serveurs inconnus, et jusqu'à maintenant, personne n'a vu ça.

Ne comptez donc pas sur Chromium pour développer en local.

Deuxième partie :

La version Chromium de développement sur Ubuntu est légèrement pénible avec les fichiers PDF. Google Chrome intègre un lecteur de ces documents, et la version que j'utilise ne le fait pas, et affiche une erreur au lieu de télécharger le fichier.

J'ai lu sur le web que l'on pouvait télécharger la librairie PDF de Google Chrome pour la mettre dans Chromium. Effectivement, après avoir récupéré Google Chrome pour Ubuntu, on trouve bien la librairie, ce qui permet d'afficher directement les PDF dans Chromium. Au passage, c'est mal fait, mais c'est encore tout neuf.

En fouillant dans l'archive de Google Chrome à la recherche de la librairie, je suis tombé sur un script sh destinés à être exécuté chaque jour (cron.daily). Son unique but est réactiver le dépôt apt de mises à jour de Google Chrome, si il est désactivé. Un dépôt de mises à jour est un élément très important au niveau de la sécurité d'un système, car il peut remplacer tout les logiciels de la machine par des versions modifiées.

Le script n'est pas trop méchant, car si l'utilisateur a supprimé le fichier, au lieu de désactiver le dépôt, il ne le rajoute pas, mais il reste cependant étrange de vouloir réactiver ce qui est désactivé.

Il faut donc bien différencier la version Google Chrome la version libre Chromium.

Troisième partie :

Je suis tombé sur Google Native Code, permettant d'utiliser du code natif X86 dans un navigateur web. De manière sécurisée, certes. Faire du code natif dans un navigateur web, je ne comprends pas. Le SDK fournit un bon nombre de librairies dont cairo, imagemagick, ffmpeg, boost… et propose de coder tout ça en C++. Ça ressemble à une très grosse usine à gaz.

Qu'ils utilisent ça pour leur OS qui va faire un flop, d'accord. Mais d'avoir ça sur Chromium, c'est aussi étrange.

Heureusement que Chromium est libre. Qu'est-ce que ça serais sinon…

Rafraîchissement automatique web

Antoine — Tue, 27 Jul 2010 16:51:25 -0000

Lorsque je développe une application web, je trouve pratique de voir le résultat en temps réel. Une solution simple dérivée d'une astuce de linuxfr permet de recharger la page automatiquement à chaque enregistrement d'un fichier.

Les outils nécessaires sont :

Le script est simple. Il se lance en passant comme argument une partie du titre de la fenêtre à actualiser, pour l'identifier. Ensuite, il actualise la page, à l'aide du raccourcis clavier de base…

#!/bin/bash while true; do inotifywait --event modify $(find . -type f -not -path \*/.\*) focus=$(xdotool getwindowfocus) navigateur=( $(xdotool search --title --onlyvisible "$1") ) xdotool windowfocus $navigateur xdotool key "Control_L+R" xdotool windowfocus $focus done

Elle est trop grosse

Antoine — Tue, 08 Jun 2010 19:21:14 -0000

Blog:blank

Antoine — Thu, 27 May 2010 18:38:33 -0000

J'ai une ip orange (évidemment), qui est en gros NAT des téléphones mobiles (pratique), qui me charge des centaines de fois par jour cette page…

Avant, c'était une page d'erreur 404, maintenant c'est une page inutile :-)

Donc, messieurs "Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; Smartphone; 240x320) Opera 8.65" et "Mozilla/5.0 (SymbianOS/9.4; U; Series60/5.0 NokiaN97/10.0.001; Profile/MIDP-2.1 Configuration/CLDC-1.1) AppleWebKit/525 (KHTML", voici une page rien que pour vous :-P

UNR et le tableau de bord

Antoine — Sun, 25 Apr 2010 11:39:05 -0000

La nouvelle version de Ubuntu Netbook Remix (10.04) intégre quelques modifications au niveau du tableau de bord en haut de l'écran.
Il n'est plus possible de le personnaliser, tout est figé. Ce choix me semble étrange, mais je ne vais pas abandonner tout les avantages de cette version à cause de cette limitation.

La solution consiste à aller trifouiller dans le système un fichier en xml. C'est pratique :-)

Le fichier /var/lib/gconf/une.mandatory/%gconf-tree.xml est donc à modifier, en root.

J'ai mis la section panel en commentaire . Mais on pourrais aussi le supprimer, une fois les réglages spécifiques à netbook remix appliqués à l'aide de l'outil gconf-editor.

Après avoir relancé la session (la flemme de relancer gconf et gnome-panel), tout redevient comme avant.

WebSockets, ou la mise en abîme de TCP

Antoine — Sat, 10 Apr 2010 18:05:19 -0000

Le web est basé sur le protocole HTTP, protocole client-serveur qui a une communication entre le client et le serveur en deux étapes. Le client après avoir ouvert une connexion fiable, fait une requête sur une ressource caractérisée par une URL, et le serveur renvoi le résultat correspondant, et ferme ensuite la connexion.

Le protocole est assez simple à comprendre, et sa forme textuelle facilite beaucoup la compréhension. Voici un exemple très simple:

GET /index.html Réponse du serveur

Ce principe de conception n'est pas adapté aux applications en temps réel, car bien trop lourd pour leurs utilisations du réseau.

Par exemple, pour un client IRC (chat en ligne) sur le web, il n'est pas possible d'avoir les messages qui arrivent en continu.

Cependant, la version 1.1 de HTTP propose de ne plus fermer automatiquement la connexion après chaque requête, pour accélérer la navigation sur le web. Cette fonctionnalité s'appelle le keep-alive.

Une astuce classique est donc de faire pleins de requêtes HTTP à la suite qui sont en attente des messages. Quand un message arrive, le serveur écrit le message dans le flux, termine la requête, et passe à la requête suivante. Cela permet en une seule connexion d'avoir un temps réel plus ou moins précis. Car le protocole HTTP est assez lourd en contenu.

Mais même avec cette astuce, il est impossible d'écrire et de lire dans la même connexion. Pour des jeux en réseau, il faudrait ouvrir de nombreuses requêtes en même temps. De plus, utiliser des astuces de ce type n'est pas vraiment beau.

Bref, le protocole HTTP n'est pas du tout adapté au applications en temps réel, et il fallait trouver une solution.

Une solution simple et efficace aurait été de fournir une API TCP et UDP dans les navigateurs webs, mais ces derniers sont très liés au protocole HTTP, et ils ne peuvent descendre les couches du modèle OSI pour toucher au transport des données. HTTP faisant parti de la couche application, le protocole n'a pas à savoir ce qui tourne en dessous de lui, et le navigateur ne peut ainsi donc pas utiliser directement TCP ou UDP.

C'est là qu'arrive WebSockets, qui est une couche de transport au dessus de HTTP, tout ça dans un navigateur web. Son fonctionnement est cependant assez étrange, par son implémentation au dessus du protocole HTTP, ce dernier étant dans la couche application. On a donc une petite incohérence au niveau de la pile de protocoles du modèle OSI. Il y a une couche transport au dessus d'une couche application. D'où la mise en abîme dans le titre.

WebSocket possède une api en javascript de bonne qualité, et son utilisation pourrait exploser dans les temps à venir.

Il est possible de s'amuser avec dans les dernières version de WebKit, en attendant une possible implémentation dans les autres navigateurs webs. La guerre des navigateurs webs étant de nouveau d'actualité.

Malgré tout, le protocole s'éloigne beaucoup de HTTP, en abandonnant le texte pour des codes contenus dans des octets, et cassant la comptabilité avec les serveurs webs. Car l'écriture par le client durant l'envoi des réponses par le serveur change beaucoup le fonctionnement d'un serveur web. Les serveurs mandataires webs sont eux aussi touchés, et il semblerait que si certains arrivent à gérer le fait que le client puisse écrire durant la réponse du serveur, d'autres n'aiment pas du tout cette éventualité.

L'arrivée sur le web ne peut donc pas se faire d'un coup, et il existera toujours des problèmes avec les vieux logiciels, ou le vieux matériel.

C'est un bon essai, mais ce n'est toujours pas demain que l'on pourra avoir un bon client IRC sans hacks pas beaux dans un navigateur web.

Sources:

Illustration théorie des cordes

Antoine — Sun, 14 Feb 2010 10:46:42 -0000

Ça trainait dans le disque dur, autant que ça traine aussi sur le blog.