BDnum est un nouveau site web BD lancé lundi dernier, dont la particularité est d’être orienté vers les smartphones.

Même si le site est à priori très axé iPhone, leurs créateurs ont fait le choix intelligent, et à la place d’une application spécifique iPhone, ils ont développé une application web, qui peut être utilisée depuis n’importe quel smartphone (et même depuis un ordinateur de bureau).

Et le résultat est à la hauteur ! J’ai testé le site depuis mon Android (Motorola Milestone) et c’est un vrai plaisir à utiliser. Les planches disposés en vertical, case par case, aucun zoom a faire, un scrolling horizontal pour les menus. Bref, on voit que les développeurs se sont imprégnés des bonnes pratiques de développement web vers des terminaux mobiles.

Assez de technique, et le contenu ?

Et bien, pour le contenu, une planche par jour de lundi à vendredi, des adaptations de notes de blogs BD.
De cette façon, BDnum ne se limite pas à nous proposer une planche par jour, il permet aussi de découvrir chaque matin un nouveau blog BD.

Dans cette première semaine on a déjà eu des planches de Jul, Djouet Terreur graphique. Parmi eux, je ne connaissais que Jul (dont le blog est dans mon Netvibes depuis longtemps ). J’ai bien aimé la planche (et le blog) de Djou, et un peu moins celle de Terreur Graphique, mais en tout cas j’ai apprécié de me connecter sur l’appli chaque matin pour lire la planche du jour.

Bref, un très beau projet que j’espère qui aura une longue vie. A suivre et à imiter !

En 1995 le web était bien différent à celui qu’on connaît aujourd’hui. Très peu de sites web (l’immense majorité desquels étaient des sites d’universités et des centres de recherche), peu de serveurs web (presque exclusivement le vénérable NCSA HTTPd), peu de navigateurs (Mosaic et un nouveau venu appelé Netscape Navigator) et peu d’utilisateurs (des universitaires, des chercheurs, des geeks de la première heure).

Et c’est dans ce terrain que le 23 février 1995 apparait la première version d’un logiciel qui allait jouer un rôle clé dans l’expansion grand public du web : le serveur web Apache HTTP Server.

Conçu initialement comme un fork du NCSA HTTPd censé corrigé des bugs de celui-ci, Apache HTTP Server est vite devenu le serveur web de référence, ayant encore aujourd’hui une part de marché de plus de 50%.

C’est donc aujourd’hui 23 février 2010, que Apache HTTP Server fête son 15^ème anniversaire.

Joyeux anniversaire, Apache !

Vous pouvez lire plus de choses sur l’histoire d’Apache HTTP Server sur le site de la fondation Apache.

La semaine dernière s’est tenu à San Francisco l’édition 2009 de l’Intel Developer Forum. Pour les fans du hardware, c’est un rendez-vous incontournable (presque autant que les conventions Apple pour ceux qui aiment les gadgets), où Intel présente les nouveautés qui seront bientôt commercialisées et annonce les futures évolutions technologiques.

N’étant pas un passionné des micro-processeurs, mais étant quand même un fan d’électronique, le point que j’ai préféré dans les compte-rendus de ce IDF 2009 sont les photos de Sean Maloney avec des versions des puces Core i7 et Atom construites avec la technologie 1000 nm utilisée à l’époque de l’i386.

Intel Core i7 avec technologie i386

Images (C)2009 Anandtech

Il ne faut pas oublier que là ou le i386 avait des transistors de 1000 nm, les modèles actuels chez Intel sont construites avec des transistors de 45 nm, soit 20 fois plus petits.

Si ce Core i7 version i386 était branchait, on estime que sa comsomation serait autour de 1000 watts à lui tout seul, avec une vitesse d’horloge qui serait au plus de 100 MHz…

Intel Atom avec technologie i386

Images (C)2009 Anandtech

Ces Core i7 et Atom sont donc un des plus beaux exemples pratique de la loi de Moore, non ?

Trouvé via Anandtech

Après l’humour geek, revenons à un billet un peu plus technique…

Je l’ai dit souvent, et je le répète, internet arrivera toujours à me surprendre.

Hier je discutais avec de collègues sur comment faire communiquer un script shell avec une application web en Java sur l’intranet. La solution la plus simple était sans doute de faire un point d’entrée sur l’application Java, une petite servlet à laquelle on appellerait depuis le script shell via wget ou curl.

Quelqu’un a suggéré, à moitié en blaguant, d’implémenter la communication sur la forme d’un vrai web service (WS) en SOAP, avec son WSDL et tout. Je ne vais pas rentrer dans les avantages ou les inconvénients des WS en SOAP vs une approche REST, car c’est un peu philosophique comme débat. Il suffit de dire que pour ce petit besoin c’était un peu exagéré de devoir implémenter un WS SOAP, et on est donc partie sur l’approche REST avec une simple appelle sur l’URL de la servlet.

Ce matin le sujet est revenu dans la conversation et je me suis mis à penser comment on aurait pu faire si on avait eu vraiment besoin d’utiliser des WS complexes, avec SOAP, sécurité, cryptage…. Dans ma tête il aurait fallu développer le client WS à part, en Java par exemple, et appeler ce client depuis mon script shell.

Et là, je me suis dit qu’à coup sûr il y aurait quelqu’un sur le net qui a implémenté un client WS SOAP fait pour être appelé depuis en ligne de commandes, une sorte de wget pour des appels webservice. Un passage rapide par Google m’a permit de confirmer mon intuition, il y en a bien des implémentations de clients SOAP utilisables depuis un script shell !

Je suis allé donc voir WSF/C, un framework pour des WS écrit en C standard, compatible avec les implémentations Apache WS-* (dont Axis2). Ce framework inclut un client WS en ligne de commandes, wsclient, que on peu utiliser d’une façon semblable à wget ou curl.

L’implémentation est assez complète, pouvant supporter des différentes schémas d’authentification et cryptage. Le programme se pilote depuis la ligne de commandes, d’une façon assez simple pour ceux habitués à utiliser des programmes sur le shell.

Par exemple, pour appeler les WS Amazon, il suffit de faire :

où item_search.xml est un fichier XML respectant le format SOAP des WS Amazon. Par exemple :

Est-ce que c'est utile ? Peut-être pas pour une utilisation quotidienne, mais lorsqu'on veut faire des tests sur un serveur n'ayant pas d'interface graphique (ne pouvant donc pas utiliser des outils telles que SoapUI), c'est une façon beaucoup plus rapide, simple et sympa que devoir tout faire avec curl ou devoir programmer un client Java pour le faire.

Bref, un petit outil curieux pour garder sous la main au cas où on pourrait en avoir besoin...

Oui, vous avez le droit de dire que j’ai un humour pourri…

Comme je vous ai déjà raconté, mon premier ordinateur était un IBM PC 5155 équipé d’un puissant processeur Intel 8088 à 4.77MHz.

Depuis, j’ai passé par presque toute la gamme de processeurs de la famille du 8086 : d’abord le i286 du IBM PS1, ensuite le i386DX du IBM PS2, ensuite le i486DX4-100 de mon premier clonique, avec sa vitesse incroyable de 100 MHz. Et à partir de là, j’ai commencé à monter moi même mes ordinateurs, et à les mettre à jour régulièrement. Là il y a eu des Pentium, Pentium 2, Pentium 3, Celeron, Pentium 4, Centrino, divers AMD…

Bref, comme la plupart des geeks de ma génération, j’ai connu pas mal des processeurs de la famille du 8086, ils font partie de mon histoire personnelle. Et c’est pour cela que j’ai trouvé très intéressant l’article de MaximumPC dont je veux vous parler aujourd’hui : A Brief History of CPUs: 31 Awesome Years of x86.

L’article fait une rétrospective assez complète des principaux processeurs de la famille x86, dès l’humble Intel 8086 aux recents Intel Core i7 ou AMD Phenom II. Le tout, sans trop rentrer dans des technicités, et avec plein de petites notes curieuses (du type Did you know that…) qui font plus agréable la lecture.

Trouvé via Gizmodo.

Je ne sais pas si ce petit tutoriel servira à quelqu’un d’autre que moi, car c’est vraiment quelque chose de assez particulier. Mais étant donné que cela m’a fait perdre un peu de temps vendredi dernier, je me suis dit qu’il valait mieux le mettre par écrit. Et quitte à le faire, autant le mettre sur le blog, où ça peut peut-être depanner quelqu’un dans la même situation.

Le problème, à la base, c’est que j’ai tendance à oublier les possibilités offertes par les tunnels SSH. Ou plutôt, j’ai tendance à les considérer plus compliqués qu’ils ne le sont et du coup ne songer à les utiliser qu’en dernier ressort.

Mais à chaque fois que je me décide à les utiliser, je constate que les tunnels SSH en plus d’être très puissants ne sont pas compliqués, il suffit d’avoir les idées claires.

Description du problème

Vendredi dernier j’étais confronté à un problème en apparence simple mais qui m’a pris la tête pendant un moment.

J’avais un gros volume de données (en occurrence un fichier grosfichier.tgz de plusieurs gigas) à copier entre deux machines distantes. Ces deux machines étaient dans deux VLANs différentes et elles ne se voyaient pas. Appelons sourcetux à la machine qui a le fichier et cibletux à la machine sur laquelle on veut le copier.

J’avais sous la main une troisième machine, que nous appellerons passepartouttux, qui avait accès aux deux machines précédentes, mais où je ne pouvais pas stocker des données (pas de place disque).

Comment faire donc pour transférer mon gros fichier entre les deux machines ?

La solution

La solution la plus simple (et la moins efficiente) aurait été de copier le fichier sur passepartouttux et de le renvoyer ensuite vers cibletux. Mais passepartouttux étant une machine avec un petit disque déjà surchargé, cette solution ne risquait pas de marcher.

Ma première idée était d’utiliser scp depuis passepartouttux pour copier de sourcetux à cibletux, mais j’ai vite remarqué que cela ne pourrait pas marcher, car il aurait besoin d’établir SSH entre sourcetux et cibletux.

J’ai ensuite cherché des possibles alternatives simples, mais aucune ne convenait.

Lorsque j’ai posé la question à mon collègue Fred, il m’a dit sans hésiter d’utiliser des tunnels SSH. Ma première réaction a été plutôt négative, ça me semblait une procédure assez lourde pour une toute petite opération. Mais lorsque j’ai bien réfléchi, je me suis rendu compte de que Fred avait (encore une fois) raison, utiliser des tunnels SSH était non seulement une bonne solution mais aussi une solution simple.

La seule particularité du cas c’est que depuis passepartouttux on peut se connecter à sourcetux et à cibletux, mais depuis sourcetux et cibletux on ne peut pas se connecter à aucune des autres deux machines. En conséquence, passepartouttux devait être à l’origine des deux tunnels.

Des passepartouttux on ouvre donc un tunnel dont l’entrée est le port 10000 de sourcetux et la sortie le port 10000 de passepartouttux :

Ensuite on ouvre un autre tunnel depuis passepartouttux, cette fois avec son entrée dans le port 10000 de passepartouttux et la sortie le port 10000 de cibletux :

On vient donc de créer un tunnel virtuel entre le port 10000 de sourcetux et le port 10000 de cibletux.

Maintenant il suffit d’aller sur cibletux et se mettre à l’écoute sur le port 10000, redirigeant la sortie vers un fichier, et d’aller sur sourcetux pour envoyer le fichier vers son propre port 10000. Pour les deux opérations, la commande magique est netcat, nc.

Côté récepteur :

Côté émetteur :

Et le tour est joué !

Comme je vous disais lorsque je parlais de la bataille d’Hoth en LEGO, en regardant certains projets je me dis que je ne mérite pas vraiment le titre de geek.

Le dernier exemple c’est celui de The LEGO Computer, que j’ai trouvé grâce à The Brothers Brick.

The LEGO Computer est le projet d’un passionné de LEGO et des ordinateurs, qui en 2003 a construit avec son gamin un boitier d’ordinateur fait intégralement avec des briques de LEGO. Sans vise, sans colle, tout est tenu par des bonnes vieilles briques de LEGO.

Apparemment la machine tourne 24h/24, utilisée comme serveur de messagerie, sans aucun problème de sur-chauffage grâce à une architecture bien pensé qui facilite la dissipation de chaleur.

Et voici une petite vidéo qui montre le démarrage de l’ordinateur (en Windows 98 quand même ).

J’ai adoré lorsque à la fin de la vidéo l’ouverture du lecteur CD caché derrière la porte du garage. Voici une autre photo du ce garage-lecteur CD :

Les images de ce billet appartiennent à legocomputer et elles ne sont pas couvertes par la licence Creative Commons

Mais il y a une chose que je ne suis pas capable de mettre à la poubelle : des livres. Pour moi jeter un livre aux ordures est presque un sacrilège, quelque chose intrinsèquement mauvaise.

Cependant j’ai bien trouvé des bouquins que je sais positivement que je ne vais plus jamais lire. Ces qui sont des livres de jeux de rôles partiront cette semaine vers LudikBazaar, où ils feront le bonheur du roliste qui les achètera. Les romans en français seront données à une bibliothèque (ceux en anglais et en espagnol je verrai plus tard). La seule catégorie qui me posait donc des problèmes était celle des livres techniques d’informatique.

Comme la plupart d’informaticiens, au cour des années j’ai cumulé pas mal de livres d’informatique, en anglais en français. Je me voit mal donner ça à une bibliothèque, et je ne veux pas les jeter, j’aimerais qu’ils sert à quelque chose. Alors j’ai décidé de les proposer ici, dans mon blog.

Ces livres ne font actuellement qui occuper de la place ici. J’ai donc décidé de les proposer à un prix imbattable : 0€ plus les frais d’envoi. Si vous voulez l’un de ces livres, il suffit de me le dire et m’indiquer votre adresse. Ensuite j’irai à la Poste, je demanderai les frais d’envoi et je vous les communiquerai, pour voir si vous êtes d’accord. Si oui, vous m’enverrez les frais d’envoi par chèque ou Paypal et je vous expédierai le bouquin.

Tous les livres ont été très utilisés, mais ils sont en bon état, je prend bien soin de mes bouquins. Pour chaque livre je donne le lien Amazon pour obtenir plus d’information sur le bouquin. La liste de livres à donner est :

Livres en français :

Livres en anglais :

Donc voilà, si l’un de ces livres vous intéresse, envoyez moi un e-mail à