Greg's blog

Des applications web vraiment libres ?

Greg — Wed, 25 Mar 2009 00:18:00 +0100

Aujourd'hui l'actualité m'encourage à prendre du temps pour partager quelques reflexions à propos du logiciel libre. L'article de Richard Stallman (RMS)^[1] sur gnu.org, The Javascript Trap, fait du bruit. Il me semble mal compris. Deux autres nouvelles intéressantes : une opinion que Eric S. Raymond (ESR)^[2] qualifie lui-même d'hérésie, reprise dans Eric S. Raymond speaks heresy; et l'abonnement obligatoire à last.fm Radio^[3] pour les utilisateurs hors US, UK et Allemagne. Note : cet article est en cours de rédaction, mais j'ai decidé de le publier pour pouvoir bénéficier de retours si quelques lecteurs s'égarent sur ce blog. N'hésitez donc pas a ajouter vos commentaires. J'en prendrai compte pour faire évoluer ce post. Voir l'avis de Marc dans Le piège du JavaScript.

L'essai de RMS décrit l'exception qui existe actuellement sur la partie cliente des applications web. Il se concentre sur le langage Javascript mais n'exclut pas d'autres environnement tout aussi problématique - voire davantage - comme Flash, Silverlight ou les applet Java. Le Javascript est utilisé actuellement pour créer de vraies applications^[4]. Dans ce cas, si l'on adhère aux principes du logiciel libre, il semble évident que ces applications Javascript non triviales doivent également être libres. Si c'est le cas, l'utilisateur devrait pouvoir exécuter une version modifiée à la place du code original. Certaines réactions ont dénoncé une position quelque peu extremiste de RMS. Cependant, son exposé est clair et je partage son point de vue : à partir du moment où l'on utilise une application, on peut exiger qu'elle soit libre. Le langage dans lequel l'application est écrite n'y change rien.

Cet essai a l'intéret de soulever le problème plus général du manque d'applications web libres. Il y fait allusion brièvement, en indiquant qu'un texte complémentaire lui serait dédié. Si je prend mon exemple personnel, j'essaie autant que possible d'utiliser des logiciels libres. J'installe des Debian GNU/Linux sur toutes mes machines (mes serveurs Gandi ou mes machines personnelles), et n'installe presque exclusivement des applications libres. Je dis bien "presque" car malheuresement dans certains cas, je ne peux m'en passer. Un exemple simple est flashplayer qui même s'il peut être en partie remplaceé par Gnash^[5], reste parfois indispensable... je le regrette. Cependant j'utilise des services web. Et c'est là que s'illustre l'autre face du problème. J'utilise twitter qui n'a rien de libre, juste une API documentée. Paradoxalement j'utilise twidge comme client, qui lui est libre mais cela ne résout rien. Alors bien sûr, vous me direz, "utilise identi.ca qui a ouvert son code !"; ce n'est pas faux, mais je me heurte alors à un autre problème : la base utilisateur. Ce problème je l'ai déja rencontré avec la messagerie instantanée. Fervent promoteur de Jabber, jusqu'à installer un serveur^[6] et commencer à designer un client^[7], j'ai du me résoudre à me créer un compte MSN que j'utilise chaque jour pour discuter avec des amis. Dans le cas de MSN, si je décompose la pile logiciel, nous trouvons le serveur - et probablement les proxy -, le protocole, et enfin le client. De nombreux clients libres existent^[8]. Pour les serveurs c'est autre chose puisqu'ils sont propriétaires et maintenus par Microsoft MSN. Et enfin du côté du protocole ce n'est pas mieux. Tout ceci est bien déprimant ! Mais finalement pour les applications est-ce vraiment mieux ? gmail, twitter, last.fm... que d'applications propriétaires ! On y gagne tout de même un protocole souvent standard (HTTP Rest ou autre) et une API documentée, mais pas libre. Cela a permis d'écrire des clients libres, et d'avoir le plaisir d'en trouver en Haskell (twidge).

Pourquoi vouloir une application web libre ? Et bien, ce sont les mêmes raisons que pour les autres logiciels. Je veux pouvoir le comprendre, l'adapter à mes besoins, le ré-utiliser pour d'autres projets. Le code, au même titre que des livres, représente du savoir. Du savoir appliqué certes, mais du savoir quand même. Les fondateurs des figures de proue du web2.0 rétorqueraient probablement qu'ils doivent garder leur avantage concurrentiel, leurs petits secrets et ne pas faciliter la l'apparition d'offres similaire qui utiliseraient la même base logicielle. Cet argument n'a rien de nouveau. Dans certains domaines, il est plausible. Elaborer un modèle économique viable, voire - osons-le - efficace, demande de la créativité. Il n'en demeure pas moins désuet à une époque où nombre de grands éditeurs^[9] expriment leur attrait pour le logiciel libre. Ce serait naïf de les croire philanthropes, Ils voient dans le logiciel libre un modèle efficace qui répond à leurs besoins sur certains segments de marché. Dans son essai Open Source and the Commodization of Software^[10], Ian Murdock^[11] expose comment le logiciel libre s'est imposé de facto dans certains domaines. Cela s'est fait en partie en rendant le code source accessible facilement. Ensuite pour générer des revenus, des offres à valeur ajoutée sont construites au-delà du code source. Ses offres vont du conseil, à l'adaption du logiciel en passant par l'externalisation de l'exploitation du logiciel.

Ces voies me paraissent envisageables pour des applications web. Certaines entreprises ont décidé de les suivre. identi.ca propose un service hébergé. L'utilisateur n'a pas à se soucier de l'exploitation du logiciel - ici Laconica -. Un autre modèle consiste à implémenter en priorité les fonctionnalités demandées par les utilisateurs qui paient. La démarche repose alors sur l'adaption du logiciel aux besoins de l'utilisateur. Si certains voient dans le mouvement du logiciel libre un idéalisme forcené, il serait temps d'équilibrer cette vision et de comprendre les avantages économiques qu'il apporte. A suivre...

Notes

[1] fondateur du projet GNU et de la FSF, a initié les projets Emacs, GCC et GDB

[2] auteur entre autres de l'essai The Cathedral and the Bazaar, du livre The Art of Unix Programming (TAOUP) et des logiciels libres fetchmail, bogofilter et gpds

[3] 3 dollars ou 2.50 euros par mois

[4] il prend l'exemple de Google Docs dont le code Javascript obfusqué représente environ 500k

[5] par ailleurs classé dans les projets prioritaires de GNU

[6] malheuresement jabberd à l'époque

[7] repris par de très bonnes mains, ma contributions fût vraiment mineure

[8] j'utilise bitlbee et kopete

[9] Sun avec la libération de Java et de Solaris, ainsi que le rachat de MySQL, IBM par ses multiples contributions à des projets libres dont Linux et malgré quelques brevêts mal venus, et Apple

[10] Open Sources 2.0, O'Reilly, 2005

[11] Le ian de Debian, aujourd'hui chez Sun

Optimisation du blog

Greg — Wed, 19 Nov 2008 07:38:00 +0100

Les quelques lecteurs de ce blog ont du remarquer qu'il était lent a charger : 8.573 s pour la page d'accueil, c'est ... très très long. Il est pourtant hébergé sur deux parts gandi, ce qui est largement suffisant - bien qu'il y ait d'autres services et sites web sur ce serveur. 512 MB de RAM, avec de la RAM de libre. Curieux de trouver d'où provenait cette lenteur, j'ai pris un peu de temps pour profiler dotclear et ajouter des mécanismes de cache.

Profiling de dotclear

Le profiling est une technique courante pour trouver les bottleneck dans du code. Il est implémenté soit dans le compilateur (dans le cas d'un langage compile) soit dans l'interpréteur ou une extension.

Installer xdebug :

$ aptitude install php5-xdebug

Ajouter dans /etc/php5/conf.d/xdebug.ini :

zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so
# append ?XDEBUG_PROFILE=1 to profile an url
xdebug.profiler_enable_trigger = on
xdebug.profiler_output_dir = /tmp/xdebug

Pour profiler une url, tapper l'url et lui ajouter ?XDEBUG_PROFILE=1 Lorsque la page est traitée, des fichiers cachegrind.out.xxx sont crées dans /tmp/xdebug.

Ensuite j'utilise kcachegrind (très pratique aussi pour analyser les résultats d'OProfile et Valgrind) pour analyser le profile.

Et la je vois 2 936 appels a netSocketIterator->current . Surprise ! Juste au-dessus, le coupable est enfin dévoilé : tplamis::amisWidget. Le widget pour récupérer des feeds ! Entre la connexion au serveur distant, la récupération du feed et le parsing du xml, ça a de quoi faire ramer le chargement de la page.

Donc zou' ! Suppression des widgets d'agrégation de flux qui n'étaient pas très utiles de toutes façons.

Deuxième phase, ajout de mécanisme de cache

Ici rien de bien complique non plus puisqu'il s'agit essentiellement d'installation de softs : xcache pour php, memcached et le plugin memcache pour dotclear.

xcache est implémenté un cache et un optimisateur des opcodes php.

$ aptitude install php5-xcache

Ajuster les variables xcache.size et xcache.optimizer dans le fichier /etc/apache2/php5/xcache.ini :

xcache.size = 32M # ou plus selon vos besoins
xcache.optimizer = On

note : nécessite d'ajouter le repo lenny ou un repo de backports.

memcached est un serveur de cache distribue. Il écoute par défaut sur localhost:11211 :

$ aptitude install memcached

Et enfin télécharger le plugin memcache pour dotclear2 puis le décompresser dans le repertoire plugins/ de l'install dotclear sur le serveur.

Consommation mémoire par Apache2 et nginx/php5-fastcgi

En bonus un petit comparatif :

$ ps -o cmd,pid,rsz,vsz -C php5-cgi
CMD                           PID   RSZ    VSZ
/usr/bin/php5-cgi           26576  5172  50344
/usr/bin/php5-cgi           26577  5172  50344
/usr/bin/php5-cgi           26578 16892  56468
/usr/bin/php5-cgi           26579  2076  50344
/usr/bin/php5-cgi           26580  2076  50344
/usr/bin/php5-cgi           26581  2076  50344
/usr/bin/php5-cgi           26582  2076  50344
/usr/bin/php5-cgi           26583  2076  50344
/usr/bin/php5-cgi           26584  2076  50344
/usr/bin/php5-cgi           26585  2076  50344
/usr/bin/php5-cgi           26586  2076  50344
/usr/bin/php5-cgi           26587  2076  50344

(lancé avec /usr/local/bin/spawn-fcgi -f /usr/bin/php5-cgi -F 2 -s /var/run/nginx/fastcgi.sock -u www-data -g www-data)

Et nginx :

CMD                           PID   RSZ    VSZ
nginx: master process /usr/ 13828   440   2648
nginx: worker process       13829  1084   2808

Et pour apache2 :

CMD                           PID   RSZ    VSZ
/usr/sbin/apache2 -k start  24880  8464  54824
/usr/sbin/apache2 -k start  24885 15116  57520
/usr/sbin/apache2 -k start  24886 16116  58004
/usr/sbin/apache2 -k start  24887 13292  56576
/usr/sbin/apache2 -k start  24888 15308  57896
/usr/sbin/apache2 -k start  24889 13528  56620
/usr/sbin/apache2 -k start  25196 13780  56728
/usr/sbin/apache2 -k start  26564  4520  54956

note : rsz = mémoire résidente (RAM physique), vsz = mémoire virtuelle (allouée par l'application mais par forcément utilisée, et répartie entre la RAM et la swap).

Bien sur ça évolue en fonction des scripts qui sont appelés, mais ça donne un petit aperçu de la différence.

Par exemple, je viens de charger la page d'accueil du blog servie par nginx et j'ai maintenant :

CMD                           PID   RSZ    VSZ
/usr/bin/php5-cgi           13812  5172  50344
/usr/bin/php5-cgi           13814 17188  55820
/usr/bin/php5-cgi           13815  5172  50344
/usr/bin/php5-cgi           13817 13096  53376
/usr/bin/php5-cgi           13820  2076  50344
/usr/bin/php5-cgi           13831  2076  50344

Conclusion

Comme l'a dit Don Knuth, il ne faut pas optimiser prématurément (à part sur des parties évidentes ou des algorithmes bien connus pour une tache précise). Il faut surtout analyser le comportement de l'application et découvrir ses goulots d'étranglement. Comme on l'a vu ici c'est l'usage inapproprié (ou sans trop de réflexion préalable) qui ralentissait le chargement. En continuant la démarche de profiling et d'analyse il sera possible de découvrir les fonctions appelées trop souvent ou les requêtes mysql qui seraient trop coûteuses.

D'autre part, ça souligne qu'il n'est pas toujours - voire rarement mais il faudrait le démontrer ;) - optimal d'intégrer un peu tout dans un application web et de l'exécuter à la demande (ou à chaque chargement) certaines fonctions. Dans le cas d'un agrégateur il sûrement plus efficace de lancer une tache cron regulierement pour générer du html qui serait charge par un plugin.

[edit] Si vous passez par là, n'hésitez pas à me laisser un commentaire avec le temps de chargement de la page dans votre navigateur ;).

I'm back

Greg — Mon, 17 Nov 2008 22:30:00 +0100

Et oui de retour après... longtemps. Plein de prévisions, quelques réflexions, plein de projets mais finalement peu de concret sur ce blog. Pourtant il s'est passé des choses depuis. Un nouveau design (quelques changements dans la css) pour changer et pour que vos ecrans consomment moins d'énergie. J'ai finalement mis django de côté, je suis de loin les évolutions qui touchent le projet et m'intéresse toujours aux questions techniques qui concernent le framework mais j'ai plutôt jeté mon dévolu sur des framework bases sur des langages fonctionnels comme haskell (HaPPS) ou scheme (PLT-Scheme Continue). Le distribué et notamment erlang et les framework Map/Reduce (Hadoop, Disco...) m'attirent également beaucoup. Mon intérêt se porte également sur la visualisation d'informations et l'intelligence artificielle (a un niveau basique).

Nouveau job : virtualisation, développement kernel / système et du python. J'ai pu redécouvrir le C++ avec un autre regard. Bien qu'il reste difficile d'avoir le même niveau d'abstraction que des langages comme haskell, ocaml ou scheme; c'est agréable d'avoir :

un typage plus fort que le C,
une utilisation la plus systèmatique possible de const (sur lequel g++-4.3 est assez rigoureux comparé a du C avec gcc-4.x)
les references (pour éviter de passer des pointeurs non initialisés),
les functions classes pour avoir un mécanisme plus sûr de pointeur sur fonction,
les exceptions (avec la documentation des expressions susceptibles d'être levées par la fonction, dans son prototype i.e. int fonction(a, b, c) throw (runtime_error);
les templates pour disposer de structures génériques (avec modération pour ne pas avoir un binaire trop avide de mémoire)

J'essaie de minimiser le recours a des libs externes, donc je n'utilise pas boost par exemple, même si elle apporte certains mécanismes assez pratique comme les fonctions anonymes (lambda), la composition de fonction, etc ... C'est un choix pour limiter les dépendances externes. Ca ne manque pas tant que ça au final. Dans les documents utiles, la page Bjarne Stroustrup (concepteur du langage), la FAQ Lite, un Technical Report on C++ Performance, un pdf d'Oleg (attention mine d'or !), et bien sûr le livre le Langage C++ de Bjarne Stroustrup.

Après avoir parlé de manière récurrente de langages fonctionnels (notamment haskell), pourquoi du C++ ? Essentiellement pour des raisons de performances (calculs et espace mémoire). Il y a peu d'abstractions car il s'agit essentiellement de programmation système avec beaucoup d'appels systèmes et probablement des parties qui seront réimplementées en module kernel (linux). Les structures de données restent simples.

Quand on pense C++, on pense programmation orientée objet. Rien ne l'impose bien sur ! Mais ça devient vite pratique d'utiliser une classe pour stocker les attributs et les fonctions (qui sont donc des méthodes) au même endroit. Un peu d'héritage, de polymorphisme et de surcharge d'opérateur et voila, sans faire dans le code objet académique, on va appeler ca de l'objet.

En parallèle je fais du Haskell, ce qui me permet de vraiment comprendre pourquoi l'accent est porte sur la séparation stricte entre les fonctions pures et celles effectuant des effets de bord. La plupart des bugs proviennent en effet, soit du manque de contraintes (qu'on peut exprimer a des guards en haskell), soit d'effets de bord mal controlés, autrement des variables inter-dépendates modifiées dans le mauvais ordre, ou encore des modifications inattendues.

Une petite note, le wiki est cassé pour le moment, j'ai fais quelques tests avec nginx (pour voir si je migrais tout dessus) et je n'ai pas encore pris le temps de le remettre bien comme il faut.

To be continued... (OProfile, haskell, HaPPS, epoll, scheme, SICP...),

Quelques nouvelles : système et sécu, programmation fonctionnelle, moteur de blog

Greg — Sat, 23 Feb 2008 10:46:00 +0100

Quelques nouvelles pour les quelques lecteurs de ce blog qui doivent se demander si j'ai perdu les clés de la cave dans laquelle je me suis enfermé. Première nouvelle, non je ne suis ni dans une cave ni enfermé mais je n'ai pas trouvé le temps d'écrire un billet avant aujourd'hui. Je me suis replongé dans le dev d'exploit sous linux en me donnant pour objectif de gérer la plupart des protections userland (heap hardening, -fstrack-protector-all, ...) et kernel (ASLR, NX, et autres, en commençant par les fonctionnalités de base du noyau 2.6, puis en continuant avec ExecShield et Pax). Dans le même temps, l'actualité récente m'a poussé à m'intéresser de plus près aux vulns kernel.

En parallèle, je garde toujours un oeil sur la programmation fonctionnelle, notamment Haskell. Je profite de mes travaux en exploitation de vuln userland et kernel pour écrire du code concret et je l'espère utile en Haskell. Pour l'instant c'est du python ou un peu de ruby (metasploit), langages très appréciés par la communauté sécurité à côté des chers dinos que sont le C et le perl. Néanmoins je pense que ces travaux autour de la sécurité se prête bien à la programmation fonctionnelle et l'écriture de DSLs. Un projet intéressant était mosvm présenté par Wes Brown au DefCon et au HITB de 2006.Il consistait en l'exécution distante de processus dans une VM Lisp. C'est dans la continuité :

de mosdef de Dave Aitel
du syscall proxying (kudos à Core Security)
des méthodes antiforensics de Grugq Remote Exec et Pluf et Ripe complétées par les travaux de Kad et Samuel
de meterpreter (et j'espère bientôt de meterpretux car meterpreter est windows only)
et d'autres projets.

Pas mal de choses intéressantes à faire en perspective :). Je vais d'abord continuer ce que j'ai commencé et saisir les opportunités d'écrire du haskell quand elles se présentent.

Pour finir, j'avais parlé du redesign de ce blog. Je me suis dit que c'était l'occasion de migrer vers un moteur de blog écrit en python et pourquoi pas - à tous hasard - reposant sur django. J'ai regardé ce qui se faisait, tenté de construire sur le django-blog de basic apps et au final je me suis rendu compte que j'avais besoin de vraiment comprendre chaque élément et de pouvoir facilement les modifier. Je m'en suis vraiment rendu compte quand j'ai commencé à écrire une classe et des outils pour importer ce blog depuis dotclear2. J'ai alors décidé de ré-écrire un moteur de blog pour mes besoins. Dans un sens, c'est dommage, car ça répartit les efforts au lieu de les concentrer sur quelques projets, mais je prend ça comme un projet perso sans ambition autre que répondre à mes besoins et sans vouloir faire un moteur de blog de plus comme dotclear ou wordpress.

Ce que j'attends en 2008

Greg — Thu, 17 Jan 2008 09:27:00 +0100

Ca ressemble à des prédictions sans en être :). Je ne suis pas voyant et les tendances que je perçois ou que j'attends sont liées aux domaines qui m'intéressent. Je ne vais donc pas m'essayer à prédire les grands évèments de 2008, mais plutôt énoncer ce que j'attends.

Les langages fonctionnels vont réellement commencer à être utilisés. Par réellement, j'entends de manière moins confidentielle. L'exemple le plus frappant est l'utilisation d'Erlang pour le service SimpleDB d'Amazon AWS^[1]. Les capacités fontionnelles de certains langages^[2] très appréciés pour le développement agile comme Ruby et Python (pour ne citer qu'eux) sont indéniablement très pratiques et rendent plus productif (et plus succinct, exemple : les list comprehension en Python). Le style fonctionnel dans ces langages est partiel, on trouve en effet des effets de bord. Avec la vogue des architectures multicore et la nécessité de faire du calcul parallèle (distribué ou multithread local), les langages fonctionnels sont très adaptés. Une raison simple à cela, ils sont fondés (pour les langages fonctionnels purs c'est même imposé) sur l'absence d'effet de bord. Par conséquent la concurrence est implémentée avec des processus qui ne partagent pas de mémoire et communique de manière asynchrone par passage de messages. C'est le style fonctionnel qui amène à cela. On trouve une bonne illustration de ce principe dans une description d'Erlang et de la raison de son succès récent What's all this fuss about Erlang? par Joe Amstrong.

C'est toujours difficile de choisir un langage de programmation quand on se lance dans un projet. Plusieurs approche se présentent : choisir celui qu'on maîtrise le mieux d'où la proéminence du C/C++, .Net, PHP et Java; choisir celui pour lequel on aura le plus de contributeurs ou développeurs à embaucher (qui a parlé de Java ?? ;) ); choisir les langages les plus appropriés pour traiter chaque composant du projet. hmmm oui vous avez bien lu LES langages. Alors bien sûr en pratique ça finit souvent par un langage, mais il n'est pas proscrit d'envisager l'utilisation de plusieurs langages. C'est d'ailleurs ce que pas mal de projets font déjà depuis longtemps en ajoutant la possibilité d'utiliser des langages de scripts^[3] dans les applications. Paul Graham mets en avant ce choix dans son essai Beating the Averages. Certains y voit l'apologie de Lisp, j'y vois surtout la mise en exergue de ce qui constitue un des avantages majeurs d'une startup sur ces concurrents : le socle technologique. Il faut batir sur de bonnes fondations, celles qui permettront de ne pas perdre de temps et de répondre à la demande. "Faut qu'ça scale!!!". Les gens qui créés des entreprises sont souvent intelligents et l'équipe technique compétente. Ce qui va faire la différence, outre les choix stratégiques, sont les choix qui vont permettre d'aller plus vite et de faire mieux. Ca n'empêche pas d'avoir des startups qui marchent en utilisant du Java, mais certains, comme Frank Sommers, se posent des questions sur l'utilisation du langage dans l'efficacité d'un framework How Does Language Impact Framework Design?. Le seul élément qui n'est pas extensible c'est le temps. Ensuite la grosse question est qu'est-ce qu'un bon langage ? Qu'est-ce qu'une bonne technologie ? Et la chacun a sa réponse en fonction de ses besoins, de son expérience et de son humeur. The Hundred-Year Language de Paul Graham^[4] est une réflexion parmi d'autres sur ce point.

Comme cela a déjà commencé, les outils, APIs et protocoles permettant la réalisation applications web riches (RIA) vont être plus en plus exploitées à des fins malicieuses. Exemples avec flash: Flash UPnP Attack FAQ et Hacking the Interwebs, et Ajax (déjà traité en 2007 dans la plupart des conférences sécurité). On surveillera d'ailleurs les travaux du W3C sur le Same Origin Policy, Access Control for Cross-site Requests, commenté Browser Security Gets Even More Confusing (Cross-site Request Draft) par Justin Schuh, et traité dans cet article Shaping the future of secure Ajax mashups sur IBM DeveloperWorks.

Le logiciel libre sur l'embarqué grand public et les téléphones mobiles va se généraliser : Google Android, OpenMoko, The BUG (qui a été gratifié d'un CNET Award au CES et massivement couvert par la presse spécialisée récemment). Je me demande comment va réagir Archos au projet OpenPMA. Soit ils le font ala Apple en essayant de tout vérouiller - ce serait vraiment moche -, soit ils décident de créer une communauté autour de leur produit et de leur plateforme logiciel. C'est un modèle économique différent car actuellement ils vendent des plugins et ouvrir la plateforme logicielle permettrait d'avoir des alternatives à leurs plugins propriétaires et donc ne pas les acheter. Cela peut constituer un pari intéressant sur l'innovation et permettre de rattraper le retard d'Archos sur Apple notamment sur la partie interface utilisateur -- pour le reste difficile de parler de retard. J'aimerais bien un PMP qui sache lire le MKV !

Notes

[1] Pourquoi Amazon a choisit erlang pour SimpleDB. J'ai une piste ici -- bien que je ne connaisse pas les détails d'implémentations de SimpleDB notamment le moteur de base de données : "Mnesia - Base de donnée temps réel distribuée pour Erlang. Mnesia supporte la réplication en mémoire vive (RAM) aussi bien que le stockage sur disque, permet la modification dynamique des schémas et permet de stocker des structures de données d'une complexité arbitraire. Mnesia est très rapide car fonctionne dans le même espace d'adressage que les applications qui l'utilise: cette caractéristique est possible, car Mnesia et les programmes qui l'utilise sont écrits en Erlang. Mnesia est un bon exemple de la puissance d'Erlang: Dans combien de langage pourriez-vous écrire un SGBD distribué, complet et de qualité industrielle en moins de 20 000 lignes de code." (extrait de Livre blanc: Le langage Erlang.

[2] Can Your Programming Language Do This?

[3] lua, perl, python, clisp me viennent en tête

[4] Deux essais cités de lui, vous allez croire que je suis fan ! Et bien pas spécialement, c'est juste que je lis Hackers and Painters en ce moment, et que son expérience est intéressante.

Bonnes fêtes ! Et un peu de teasing pour 2008 ;)

Greg — Mon, 24 Dec 2007 14:16:00 +0100

Nous sommes en pleine période de fêtes de fin d'années. Entre la course aux cadeaux et les expéditions pour voir tout le monde, le temps passe vite ! Pour ceux qui lisent ce blog et que je n'aurais pas l'occasion de voir, je vous souhaite de passer de très bonnes fêtes de fin d'années. Beaucoup de courage pour ceux qui doivent travailler le soir du réveillon et/ou le jour de Noël et qui n'ont pas pris de congés.

Nous ne sommes pas encore en 2008, mais je vais décrire un peu ce qui attend ce blog au début de l'année.

Un redesign complet : ce blog en a bien besoin ! J'avais repris le thème deep_green, de Carnegie. Et au final j'ai complètement changé les couleurs (le thème était au départ vert sur noir...). Donc oui ça ne servait à rien de prendre ce thème :p. Je vais donc reprendre ça from scratch et apprendre à utiliser Inkscape.
La suite, enfin la ré-écriture plutôt, de la réflexion sur l'avenir des applications web libres. J'ai une ébauche bien avancée de la structure et des notes de côté. Après avoir relu le billet que j'avais écrit je ne suis pas satisfait : c'est pas très clair et j'ai du mal à poursuivre la réflexion à partir de ça. Je vais donc prendre le temps - car je trouve que le sujet le mérite - et mettre l'essai en ligne courant janvier.
Une présentation d'une application web écrite avec Django. Je n'en dis pas plus pour le moment :).
+ de billets et surtout plus régulièrement. C'est probablement la résolution que l'on trouve le plus souvent chez bloggeurs, je vais essayer de m'y tenir !

Le financement des services web gratuits par la pub

Greg — Fri, 07 Dec 2007 13:08:00 +0000

Ce billet est une tentative de réponse à la question soulevée par GML, Le web gratuit a-t-il un avenir ?. Après éclaircissement de sa part, je me suis rendu compte que j'avais mal compris l'hypothèse qu'il avançait. Je vais essayer de reprendre dans le bon sens ici :).

On peut distinguer deux modèles basés sur la pub (d'après le Rapport O'Reilly Web2.0), syndicated advertising (i.e. contextuel comme AdSense) et sponsorship advertising (modèle plus classique je vends de l'espace de pub directement à une boîte). Le premier est indirect, dans le cas d'AdSense, c'est AdSense qui se débrouille avec les annonceurs et me reverse une commission. Dans le second, on négocie en gros directement avec l'annonceur (ou on passe par une régie pub). Dans les deux cas, on peut avoir un paiement par commission au clic.

Ca s'adapte avec la demande, plus il y a d'utilisateurs de mon services, plus il y a potentiellement de clics. Cependant on est tributaire de la qualité de ciblage des pubs ! Dans le modèle par sponsorship, on peut aussi vendre l'espace comme dans les média traditionnels avec un prix en fonction de l'audience du service. On a donc un prix fixe qui n'est d'ailleurs pas toujours facile à déterminer.

Considérons uniquement le syndicated advertising avec commission au clic. Qui dit commission, dit pour l'annonceur qu'il ne reverse de l'argent que lorsqu'il en gagne. En se mettant à la place de l'annonceur, on se rend compte qu'on ne peut potentiellement pas perdre d'argent (c'est très simpliste bien sûr, mais ça se tient). En revanche si on a énormément de services pour un nombre d'utilisateur constant, et un nombre d'annonceurs également constant, le revenu généré est le même (car il est une fonction du nombre d'utilisateurs) mais il est réparti sur plus de services. Plus il y a de services, moins chacun touchera (en gardant la même répartition des revenus) d'argent.

Pour résumer, on prend trois variables Ns = nombre de services, Nu = nombre d'utilisateurs et Na = nombre d'annonceurs. Le point critique est atteint lorsque Nu et Na sont fixes et que Ns continue d'augmenter. Le ratio qu'évoquait GML est donc Na / Ns (avec Ns >> Na ; dans le sens très supérieur, pas décalage vers la droite ;) ).

Maintenant que les trois principales variables (elles ne sont pas les seules, mais elles me semblent suffisantes pour le raisonnement) sont définies, je vais essayer d'étudier dans quelle mesure elles peuvent varier.

Nombre de services (Ns) : on est d'accord ça va augmenter encore pendant un bon moment :).
Nombre d'annonceurs (Na) : je pense que ça va augmenter car il y a toujours une inertie de certains domaines pour qu'ils adoptent certains modèles. Ainsi on devrait probablement voir des acteurs industriels se positionner encore plus sur le web. Bon je ne suis pas dans la pub et le marketing, donc si je me plante sur ce point, n'hésitez pas à rectifier (en commentaire par exemple, ou par mail) !!!
Nombre d'utilisateurs (Nu) : j'ai gardé ce point pour la fin car il me parait essentiel. Le potentiel d'accroissement du nombre d'utilisateurs du web est encore énorme. Ce n'est pas un hasard si les opérateurs tentent de démocratiser la 3G pour des connexions data !! Deux phénomènes peuvent faire exploser le nombre d'utilisateurs : la généralisation des accès haut débit avec connexion permanente dans les pays en voie de développement (en particulier les BRIC, Brésil-Russie-Inde-Chine) et dans les pays développés (je n'aime pas ce mot car il ne représente pas sémantiquement ce que je veux dire, mais bon...), les seniors. Dans les pays occidentaux (en incluant le Japon et la Corée du Sud) la pyramide des âges est inversée, il y a donc beaucoup plus de seniors. Pourtant ce n'est pas encore la tranche de la population la plus présente sur le web.

On voit donc que le nombre d'utilisateurs devrait augmenter. Cependant, tous les services ne vont pas bénéficier de cette augmentation. D'où l'importance de la localisation autant dans le sens services que langage, de la souplesse du service et de la compréhension des cultures. ebay s'est par exemple fait surprendre en Chine. Quelques exemples dans cette article.

Il n'y aura pas de la place pour tout le monde, mais ceux qui s'adapteront pourront tirer leur épingle du jeu. La pub a encore de l'avenir devant elle, mais devra s'adapter.

Remember VisiCalc!

Greg — Thu, 06 Dec 2007 13:45:00 +0000

And other oldies ;). I am reading Founders at Work: Stories of Startups' Early Days and one of the stories is about Dan Bricklin and the early days of Software Arts, which he co-founded with Bob Frankston. On his website, he details the history of Software Arts and VisiCalc. VisiCalc was _the_ first spreadsheet software (1-2-3 followed just after). Bob tells how Implementing VisiCalc.

I have not yet finished the book, but I already learned a lot from the first stories. I think there is a lot to learn in this book from the story of such legendary startups (see the TOC for the list).

Pour les francophones, j'ai découvert AnteMemoire TV, une émission qui retrace l'histoire de l'informatique à travers des personnes, logiciels ou matériels connus et qui ont marqué leur temps. Cela fait partie d'un projet plus globale de musée de l'informatique. L'émission AnteMemoire TV #6 parle de VisiCalc (c'est le sujet du billet quand même !!).

Dédicace spéciale à Stéphane !!! A quand une démo sur l'Apple II ? ;)

[update] Comme quoi on se refait pas, Dan a fondé Software Garden et développé WikiCalc que l'on peut voir à l'oeuvre dans cette demo (screencast en flash).

TDD: Does writing software backwards really improve quality?

Greg — Thu, 06 Dec 2007 12:56:00 +0000

If you have adopted agile development methods, or even just interested in them, Dr. Dobb's published an article Test Driven Development: Does writing software backwards really improve quality? where they tried to evaluate if Test Driven Development (TDD) really improves code quality. The article shows that TDD helps to have less critical (none where found by the QA in the article's case) bugs and less bugs in general. The developer's feedback - the one who wrote the code used in the evaluation - is worth the reading:

The TDD code was refactored several times during development. Methods were created, then changed, and then changed again with each revision, resulting in code that was tighter or clearer. The developer felt like the code went through an extensive proofreading cycle similar to what is done for newspapers, magazines, or the like.
There was a freedom of experimentation that led to better design decisions. Once the first working version of a class method was completed and properly tested, the developer could then try new design ideas. The unit tests quickly confirmed or denied that the new code worked, providing a digital safety net.
On a number of occasions, the developer found that the TDD method forced him to slow down and think more carefully about what he was trying to accomplish. Rather than just banging out code to get the job done, he focused on writing high quality code.

This encourage me to try it in my current projects :). As they say in the introduction, writing tests before the code is not so natural ;) at first sight, but it could be fine to spend less time on bug squashing by taking some additional time to write the unit tests before.

I like this king of BUG!

Greg — Wed, 05 Dec 2007 17:35:00 +0000

Do you know Buglabs? Because I can't wait to see their BUG!! To quote the site: "BUG is a collection of easy-to-use, open source hardware modules, each capable of producing one or more Web services. These modules snap together physically and the services connect together logically to enable users to easily build, program and share innovative devices and applications.". The first modules they'll release are the GPS, videocam, touch sensitive LCD screen and accelerometer/motion sensor. The SDK is based on Eclipse and will be freely available. It aims to be an entirely opensource project (like the Chumby which is based on a linux stack and freely distributes the electronic schematics): "We are using Linux 2.6.19. In addition, the hardware schematics, BOMs and so forth will be made freely available to encourage users in forums and so on to hack, extend and enhance it (from #165 LinuxJournal)."

I'll hope they'll succeed. Currently nothing is actually available but it seems they made some demos in SF and NY. Opensource hardware is a huge thing though not so novel. Remember the beginning of Apple and the Homebrew Computer Club. Back to the source! Back to the garage! :)

Quel avenir pour les applications web libres ? (1/?)

Greg — Tue, 04 Dec 2007 10:32:00 +0000

Aujourd'hui le web est présent partout. Et comme le met en avant David Larlet, nos données personnelles se trouvent de plus en plus disséminées sur la toile. Dans ce contexte, l'avenir des applications web libres peut sembler primordial, car ce pourrait être un moyen de connaître ce qui est fait de ces données.

Le web 2.0 a amené des principes qui changent la manière de voir et concevoir les services sur le web. Si la notion d'application parait simple sur le desktop, la notion de Software as a Service (SaaS), a changé la donne des applications web. Les mashups en sont une preuve, lorsque les données sont suffisamment bien découpées - c'est à dire en unités petites et ré-utilisables -, le service est utilisé avec d'autres services pour constituer une nouvelle application. On utilisera à cet effet l'API fourni par les différentes services. Cependant, il existe toujours de manière sous-jacente une plateforme technique qui permet de mettre en oeuvre et d'assurer le service.

En résumé :

Une application libre ne garantit pas le contrôle des données personnelles à partir du moment où elle est hébergée chez un fournisseur de service.
Les offres d'hébergement gratuit ou pas cher suffisamment souples pour permettre l'installation d'environnement web variés permettent de pousser la création et la diversité technologique.
La réactivité de la communauté et la rapidité d'intégration des nouvelles technologies et normes permettra une adoption dans les entreprises.

Je vais dans un premier temps discuter de la partie plateforme technique et plus particulièrement du code. La plupart des succès du web 2.0 (flickr, facebook, basecamp, googlemaps) sont basés sur un mix toolkit et code propriétaire. Certes, elles fournissent des APIs qui permettent d'accéder aux données qu'elles détiennent et d'utiliser le service; mais elles ne permettent pas de modifier ce service par exemple. Le code dans ces cas n'est pas libre. On pourra rétorquer que yahoo, google, et autres, distribuent des toolkit sous des licences libres comme le Google Web Toolkit (GWT) et le Yahoo User Interface (YUI) Library. Oui c'est orienté RIA et donc plutôt côté client (YUI est une lib JavaScript, GWT en revanche est en Java donc côté serveur). C'est bien, mais ce sont des toolkits pas des applications complètes !

Pourquoi des applications web libres ?

A l'opposé prenons Dotclear ou Mediawiki. Ce sont des applications libres. Dans le cas de Dotclear c'est une application développée indépendamment d'un service, dans le cas de Mediawiki, c'est le moteur qui supporte le projet Wikipedia. Pour comprendre l'avenir des applications libres, il faut d'abord comprendre pourquoi elles existent. Bien sûr, ce sera difficile d'y répondre en quelques lignes, et je ne peux parler à la place des milliers de développeurs et contributeurs. Je pense que les applications libres comme toute application naissent pour répondre à un besoin. Là où elles sont différentes des applications propriétaires c'est dans l'intention de leurs auteurs. Créer une application libre c'est permettre à d'autres personnes de la comprendre, de la modifier et également de faire autre chose avec, puis de la redistribuer. Créer une application propriétaire c'est vouloir tirer un avantage concurrentiel de ses secrets industriels, de son code. Pour le revendre ou juste pour empêcher d'autres personnes de partager la même base par peur qu'elles ne fassent mieux.

L'ouverture est en partie ce qui rend une application pérenne. Si les mainteneurs d'une application libre ne peuvent plus s'en occuper, d'autres développeurs peuvent prendre la relève, et soit reprendre le projet, soit en faire un fork. Dans certains cas, les fork s'opèrent spontanément en réponse aux divergences dans le développement ou la stratégie à adopter. Si on regarde cela d'un point de vue économique, cela encourage la concurrence et l'innovation. C'est ce qui est fait du code et sa mise en oeuvre qui donne un avantage à un fournisseur de service. Cependant, les applications libres occupent peu le devant de la scène depuis quelques temps. Si la base est souvent du LAMP ou du J2EE libre, le code de l'application elle-même est propriétaire comme on l'a vu précédemment.

Dans ce sens, l'avenir des applications web libres, s'il ne semble pas en péril - je vois mal wordpress, dotclear ou mediawiki être abandonnés vu leur utilisation et les communautés qui gravitent autour - il parait en revanche un peu en retrait des applications propriétaires maison de start-up ou géants du web.

Pourquoi LAMP s'est imposé ?

PHP

En citant ces trois projets (qui me sont venus en tête sans réfléchir et sans intention particulière), on se rend rapidement compte d'une chose. Ils sont écrits en PHP. Pourquoi ? Qu'est-ce qui a fait le succès de PHP ? A présent, le langage intègre des constructions de langage moderne, mais pour ceux qui se souviennent de PHP3, c'était loin d'être la panacée ! Avant ça, on avait des cgi en Perl, voire en C et de l'asp.

Premier ingrédient du succès de PHP, il tournait sur de l'Apache (en module avec mod_php ou en cgi). C'était donc gratuit, libre et répandu. Deuxième ingrédient, c'était léger et rapide à installer. C'est sûrement un des points qui encouragea les hébergeurs et les FAI à proposer de l'hébergement gratuit ou pas cher de pages persos dynamique avec PHP. Troisième ingrédient, la syntaxe était proche du C et le langage simple. Ensuite la communauté qui s'est constituée autour du langage a apportée des libs qui ont rendu le développement encore plus facile et rapide.

L'hébergement

Remettons nous à la place d'un dévelopeur web de l'époque. Quelle est son premier problème avant même de penser à coder ? Trouver un hébergement. Il ne sert à rien d'écrire du code qu'on ne pourra pas exécuter quelque part. Il faut donc qu'il trouve un langage qui soit proposé dans des hébergements gratuits ou pas chers. Bon là on tombe dans le problème de l'oeuf et de la poule. Les hébergeurs se sont sûrement posés la question dans l'autre sens : comment fournir à mes clients un langage dynamique pour leurs pages persos ? Déjà pourquoi fournir de l'hébergement gratuit. Je ne sais si c'est totalement vrai, mais dans le cas de Free il semblerait que c'était pour peser plus dans les accords de peering. Ce qui est crédible. Je pense qu'il y avait quand même un peu plus derrière. C'est peut-être ce qui a convaincu les managers au final.

Les framework

Maintenant, les framework de développement web sont à la mode. On entends partout parler de Ruby on Rails, Django, Struts, Symfony. Les hébergements commencent à arrivés. On avait déjà le dédié pas cher (lost oasis - qui se souvient des openbrick ? ;) - puis dedibox) et les serveurs virtualisés. Cela permet de faire tourner autre chose que du PHP (avec parfois une configuration contraignante). Avec la généralisation de l'adsl (ça commence à remonter maintenant !), il est devenu facile d'héberger son site à la maison.

Disposer du code source. Pour qui ? Pourquoi ?

Pourquoi je parle de tout ça (un peu comme un ancien alors que je ne suis pas si vieux que ça ;) ) ? Parce que ce qui différencie fondamentalement une application web libre, d'une application web propriétaire, c'est la disponibilité du code. Pour une utilisation personnelle, il faut donc pouvoir "installer" ce code quelque part. Les nouvelles offres d'hébergement comme Media Temple, sont super intéressantes dans ce sens car elles permettent de proposer des environnements variés facilement et pas chers. Cela permet d'utiliser une application web libre pour ses besoins.

Et les entreprises ?

Bien sûr, les applications web sont utilisées en dehors des besoins persos. On retrouve les mêmes avantages que les autres types d'applications libres :

communauté : relecture du code par des tiers, contributions, support communautaire, réactivité
utilisation dans d'autres situations que celles prévues initialement (et donc ajout de fonctionnalités par exemple)
pérennité
transparence
gratuité

Certaines entreprises sont aussi très attachées aux valeurs éthiques du libre. Donc de ce point de vue là, l'avenir se présente plutôt bien.

Par contre que se passerait-il si des cabinets de conseil, et dans la continuité de l'externalisation, poussaient les entreprises à faire des mashup plutôt que d'utiliser des applications libres ? Cela me semble peut probable dans beaucoup de situations. Pour la simple raison que mashup implique données stockées un peu partout et sans maîtrise. Pour des données personnelles, si on l'accepte, ça peut passer. Pour des besoins professionnels, ça devient tendu !

To be continued...

Innovation Happens Elsewhere online version

Greg — Thu, 22 Nov 2007 16:55:00 +0000

Web 2.0 brings to the world and to business minds the proof that opensource models (lamp, interoperability, respect to the standards, etc...) and values (openness and wisdom of crowds) can succeed. Actually it breaks the old proprietary approach by pushing mashups and remixability that needs open and standard interfaces, let say APIs. I've ordered some books about opensource philosophy today. That's why I found in my Amazon.com recommendations Innovation Happens Elsewhere. It has good reviews that helped me to find the authors provides an online version under creative commons. Good reading ;).

No Amazon mp3 downloads outside US

Greg — Thu, 22 Nov 2007 16:33:00 +0000

sells 192 kbps without drm mp3 songs and full albums (cheaper than buying all songs individually) on Amazon.com MP3 Downloads. Unfortunately as the screenshot below shows, this is not for people outside US. And if you are a linux user, you can't natively - which means without virtualization or emulation - download full albums.

nvidia CUDA

Greg — Thu, 22 Nov 2007 09:36:00 +0000

Thanks to the Dr. Dobb's Report newsletter, I've learned about nvidia CUDA. It's a SDK that aims to use nvidia GPUs for computing. It includes a C compiler, hardware debugger based on gdb interface), and a profiler. It also includes standard FFT and BLAS libraries. For even more fun, it provides a low level assembly language layer and driver interface. CUDA is supported on Linux and Windows XP. As one may guess, nvidia only provides binary files.

A comprehensive FAQ is available.

Elcomsoft has already find a usage for CUDA, it recently made some buzz in the news (press release in pdf) by adding support for GPUs in their password recovery products. For an overview of password cracking check this except from the book Endpoint Security. Password cracking with FPGAs was presented at conferences (like Cracking Wifi... Faster! at layerone) mainly for wep and wpa cracking. But now there is a growing interest in commodity hardware (like Sony PS3 with ps3-wepcrack). In fact, why spending money and time in FPGAs if you can use commodity - almost cheap - hardware? I hope we'll see soon john the ripper using CUDA :).

Software Development round up #1

Greg — Thu, 15 Nov 2007 16:36:00 +0000

As you may know, I'm not a software developer. However I like this domain and am always happy to write some code when I need (or not ;) ). Recently I am focusing on web development (with Django) and Agile methods.

I am reading Practices of an Agile Developer which is a very interesting book. It brings some real feedback and experience, as well as good advices. I believe it is useful not only in software development but more generally in any IT (or even non-IT) project. The table of content gives a good overview of the book and the practices. The next step is to choose a agile method to focus on. Intuitively I may try eXtreme Programming at first.

Vim has always seemed to fit my needs. But I didn't try an IDE for ages, so now I give a try to PyDev, a plugin to Eclipse. I can't bear using arrow keys!!!! So I'll need to quickly find how to use vim modes. I found Vimplugin and viPlugin. ~~After a quick comparison, I'll see which to choose.~~ viPlugin is not free (neither as in free beer nor as in freedom). Thus I'll use vimplugin!

I have seen this list of python IDEs. Wing appears to be a good tool but is not free (as in freedom or even as in free beer!).

I also begin to learn more about Continuous Integration which is an important practice of Agile methods. I aim to integrate all agile practices in my programming tasks.

Google's Android SDK is available

Greg — Mon, 12 Nov 2007 18:17:00 +0000

Google has made Android SDK available. It is released under an Apache-like license. This ONLamp's article covers it. Android SDK provides an emulator environment to test it on a PC (as it is developed in Java, it should run on windows, osx and linux).

Check Android @Google Code for a detailed description and everything else about the project.

Hushmail and the feds

Greg — Thu, 08 Nov 2007 14:58:00 +0000

This morning I read the Wired's article, Encrypted E-Mail Company Hushmail Spills to Feds. In short, Hushmail - which is a canadian comparny - helped the feds to decrypt steroid dealers' mails who were using the non-java webmail service (see the comparison java/non-java configuration for details). Read also the mail thread between Kevin Poulsen and Hushmail CTO, Brian Smith. He stressed that "The key point, though, is that in the non-Java configuration, private key and passphrase operations are performed on the server- side. This requires that users place a higher level of trust in our servers as a trade off for the better usability they get from not having to install Java and load an applet.".

But one can guess that even in the java configuration, the user has to trust the Java applet. Hushmail could modify it to get the user's passphrase or not encrypt the mail between the browser and the mail server. Brian Smith told people can assess the java applet source code, but how to check that the binary java applet comes from this source code ? Even if you hash or sign the applet, it may change to correct bug or add features. So, you need to trust Hushmail and their software. In this case, one solution is to share signature or hashes between different users. It needs several third party signature repository. The counterpart is that you need at least one person from your web-of-trust to sign the binary. Another solution is to compile the applet from the source and use it instead the applet stored in Hushmail's servers. It seems to be the best solution, but I wonder if it would actually work.

It is a good reminder on encryption and trust. It is also a real life example. I remember the external reviews of Ciphire. Technical docs are interesting too. This kind of mail service add automation to e-mail encryption. This is very helpful to make adoption of e-mail encryption easier. However recipients still need to subscribe to or use the same service. One may say "why not only install enigmail or firefox's extensions that add s/mime or openpgp to common webmails??". The problem is not encrypting e-mail. The problem is in managing keys and/or certificates. That's what make automatic encryption services so helpful. You don't even need to manage your keys or to look for someone's openpgp public key.

I don't really know why e-mail encryption is so hard to adopt for private use. Even myself, I quite never encrypt or sign e-mail because I know people will not check the signature or do not have a public key or certificate. Though I have an openpgp key exported on public servers, and a cacert personal certificate (on an usb token).

Maybe it is because we don't feel the need. We only use cryptography when we believe information must be kept private and genuine. For less valuable information, there are also other way to check integrity of an e-mail (like the way an e-mail is written, or the recent discussion with the person who seems to have sent the e-mail). As often in cryptography, the main issue is key management. Once created, it's not hard to use. But the process of re-generation, revocation, etc... can be painful and boring...

That's why vendors try to use already available and daily life hardware like mobile phones (and mainly the SIM card) to store keys and certificates.

wpa_supplicant and libssl0.9.8g-2 segfaults on Debian Unstable

Greg — Thu, 08 Nov 2007 12:15:00 +0000

If like me this morning you got a segmentation fault in wpa_supplicant while trying to connect to an access point with WPA, check this Debian bug report. Upgrade to libssl0.9.8g-3 solves the issue (not yet available in upstream). Packages are available here.

N9UF Twin Tact (Ep. 2)

Greg — Tue, 06 Nov 2007 13:01:00 +0000

Ce matin mon compte Neuf mobile était enfin créé pour de bon (j'ai l'impression que quand ils disent 2 jours après l'activation de la ligne/SIM c'est deux jours ouvrés). J'ai donc pu le rattacher à mon Neuf ID principal et me créer un Neuf ID mobile pour utiliser les services multimedia. Ce que j'ai fais dans la foulée en testant la TV en stream par le wifi.

Ca marche plutôt bien. Je n'ai pour l'instant testé que quelques minutes, mais c'est fluide. ~~En revanche il manque la possibilité de tourner l'écran~~ (au temps pour moi on peut le faire très simplement). Par défaut, la vidéo s'affiche en 4/3 en tenant le téléphone clavier en bas (position normale). En cliquant sur l'écran en cours de lecture, la vidéo tourne dans le sens anti-horaire. Un nouveau clic permet de revenir à la disposition initiale.

Pour l'instant j'ai relevé les defauts/bugs suivants :

Pas de réglage du volume sur le téléphone (avec une molette par exemple)
Problème d'incateur de charge. Là par exemple, le téléphone est connecté en USB à mon laptop et je ne vois pas l'état de la charge
Un seul port USB sert à tout faire : connexion avec le PC, kit main-libre, etc...
Bascule automatique vers le GPRS quand le signal wifi est très faible. Ce point est assez moche. Pour le décrire un peu plus précisément, je me suis connecté sur la Neufbox chez des proches via le hotspot Neuf Wifi. Le signal était très faible, il fallait qu'il traverse un plancher en béton ;). Et la je lance le navigateur et hop, je vois le petit g qui s'affiche, m'indiquant que je suis passé en GPRS sans me demander quoique ce soit !

En parlant du hotspot Neuf WiFi, je me demande comment se passe l'authentification. C'est un point à regarder.

Google's Android mobile OS and Open Handset Alliance

Greg — Tue, 06 Nov 2007 09:56:00 +0000

A quick post about Ars Technica's article on Google's Android and Open Handset Alliance.

Main facts:

No hardware manufacturing but a partnership with mobile manufacturers (HTC, LG, Motorola, Samsung) and carriers
Android is a linux-based OS that comes from the acquisition of the mobile compary in 2005
Aspects of the platform will be provided under the Apache license
Full SDK for Android available next week

There is also a true free (as in freedom) mobile phone: the Neo1973 which runs OpenMoko. It is said to be available soon. Wait 'n see.