Parmi celles-ci je cite toujours l’exemple d’Amazon et de ces services AWS. Ils mettent en oeuvre le logiciel de virtualisation Xen et des distributions Red Hat Enterprise. Plus récemment encore la nouvelle offre de base de données relationnelles Amazon RDS utilise la base de données MySQL.

Mais Amazon n’est pas le seul. Microsoft annonce que son offre de cloud computing Azur supportera bientôt MySQL et Apache Tomcat.

Un constat à propos duquel Savio Rodrigues affirme :

Quand Amazon décide de mettre à disposition MySQL via Amazon RDS, il le fait sans acheter de support à l’équipe MySQL de Sun. J’ai la confirmation que Microsoft Azure supporte MySQL sans payer  la souscription MySQL Enterprise à Sun.

Si le constat est exact, la situation pourrait sembler inquiétante et avoir tendance à démontrer les limites de l’open source qui au final se fait dévorer par les services propriétaires. Un constat qui se rapproche de celui que j’ai déjà fait dans le passé : le grand paradoxe de l’open source et du cloud computing. L’un a permis l’autre qui s’est empressé de l’enfermer.

La situation est-elle pour autant désespérée ? Comme le dit Matthew Aslett, le problème ne vient peut-être que de Sun qui n’a pas su prendre le virage du cloud computing et c’est ainsi laisser prendre la place de leader naturel par d’autres ? Sun n’aurait-il pas été le mieux placé, le plus crédible ? Probablement que oui, mais il n’en a pas été ainsi.

Alors au final, le cloud computing va-t-il tuer l’open source ? Difficile de trancher, il semble cependant probable que les spécialistes de l’open source qui ne prendront pas le virage du cloud computing risquent fort de regarder passer le train tout en voyant un autre en tirer les marrons du feu.

Un virage qu’à pleinement fait prendre Canonical a sa distribution GNU/Linux Ubuntu avec la dernière version de son système d’exploitation. Celui-ci intègre désormais tout ce qu’il faut pour monter rapidement une solution de cloud computing. L’installation est même désarmante de simplicité. L’exploitation est moins simple par contre et nécessite de recourir aux services payants de Canonical comme Landscape par exemple si l’on ne veut pas être limité à la simple ligne de commande. Bien sûr au-delà de la technique, Canonical a également su se trouver un allié dans ce domaine en la personne d’Amazon évidement.

Comme toujours, le choix final incombe aux entreprises utilisatrices de ces services. Les logiciels open  source ont désormais gagné leurs lettres de noblesse et sont largement utilisés et reconnus pour les avantages qu’ils procurent. Les services de cloud computing qui les mettent en oeuvre introduisent cependant un biais. Elles utilisent de l’open source, elles le font évoluer, mais elle ne reverse pas toujours leurs évolutions à la communauté créant ainsi cette fracture dans le modèle ouvert.

A nous donc de veiller lors du choix d’un prestataire que celui-ci respectera bien un ensemble de critères permettant de définir clairement si oui ou non nous avons à faire à un service “privateur de liberté” ou bien à un service libre.

Pour aiguiller vos choix je vous conseille la lecture de ces deux liens : TIO (Total Information Outsourcing) de la FFI et le travail de Karl Dubost à ce sujet. Je passerais régulièrement en revue un certain nombre de services afin de leur appliquer ces critères comme je l’ai fait pour le service en ligne Odoo basé sur OpenERP.

[Source]

Article original écrit par Philippe Scoffoni le 01/12/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Matt Asay, un pro-open source anglo-saxon notoire qui s’est pas mal fait remarquer ces derniers temps avec quelques billets parfois simplistes ou carrément à côté du sujet a quand même un peu repris ses esprits et semble constater que l’open source n’est parfois pas assez ouvert.

Voilà probablement une réflexion qui viendra apporter de l’eau au moulin des tenants de la branche dure des logiciels libres pour lesquels tout compromis est ruineux.

Une tendance à ce que j’appellerais l’attitude open source ou l’open source “Canada Dry” et pour laquelle Matt Asay reprend le terme anglais de fauxpen source.

Mais ce n’est pas tant cette dérive sur l’utilisation du terme open source qui pose réellement question, car elle est simple à identifier et correspond à un inévitable phénomène “d’opensource wahsing”. C’est plus l’apparition d’une dichotomie entre les éditeurs qui vont utiliser une licence open source, et pratiquer un mode de développement fermé par rapport à ceux qui ont une approche communautaire et ouverte. Bien entendu cela n’a aucun rapport avec la qualité du logiciel produit.

Parmi les exemples de fauxpen source Matt Asay désigne java ou encore Android. Concernant ce dernier des changements significatifs sont apparus sur le site du projet. Google a supprimé une section indiquant la liste des pré-requis pour devenir un membre de l’équipe principale de développement. Une attitude manquant d’ouverture,car elle ferme la porte aux développeurs “extérieurs” qui voudraient s’intégrer au coeur des évolutions de l’OS.

Je ne suis pas un spécialiste du développement open source, je ne saurais donc dire si ce genre de comportement sont légions ou spécifique à certains grands éditeurs open source. Ce qui par contre me semble plus sur, c’est qu’en procédant ainsi, l’éditeur va à l’encontre de l’intérêt de l’utilisateur. Or l’utilisateur ne doit-il pas être au centre de l’approche open source ? En fermant l’accès à des développeurs extérieurs, l’éditeur rend plus difficile une éventuelle reprise de son logiciel que ce soit par un fork ou encore en cas de disparition de l’éditeur. Au final, l’utilisateur est perdant.

La définition de l’open source fait clairement apparaître dans son paragraphe 5 :

5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.

En français pas de discriminations à l’encontre de qui que ce soit, personne ou groupe. Seulement, il ne s’agit ici que de la définition d’une licence pas celle de la façon dont on doit gérer un projet open source.

Faire de l’open source en mode “licence” est relativement facile alors que le faire en mode communautaire est une tout autre chose, car il faut être capable d’accepter les “intrus”.

Les éditeurs qui font le choix de l’open source pour la licence cherchent donc avant tout à profiter de l’effet de mode et à monétiser ce qui apparaît aujourd’hui comme un avantage concurrentiel par rapport au modèle propriétaire.

Encore une fois certains penseront que l’open source n’a que ce qu’elle mérite. Je resterais plus mesuré en m’interrogeant d’ailleurs si de telles pratiques n’existent pas aussi dans des projets libres. Mais encore une fois je dois bien avouer que je manque de matière à ce sujet.

Libre à vous de partager en commentaire vos expériences en ce domaine

Article original écrit par Philippe Scoffoni le 12/11/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Ce blog, il s’agit de celui du projet Elphel. Le dernier article paru sur ce site évoque avec fair-play le fait que l’université de Stanford toute fière de sa dernière création avait un petit peu oublié de parler d’eux. Juste une petite citation dans la FAQ :

Isn’t there already a Linux camera, the Elphel?

Yes there is. In fact, our first Frankencamera prototype was built around an Elphel camera. However, these aren’t really standalone cameras. Once you add a viewfinder and power supply with batteries, you get an awkwardly sized and shaped device. More importantly you get high latency between the sensor and viewfinder. That’s why we switched to a board, based on the TI platform, that includes an LCD touchscreen.

Est-ce qu’il n’y a pas déjà une caméra sous Linux, l’Elphel .

Oui c’est vrai. En fait, notre premier prototype de Frankencamera  a été construit autour d’un camer Elphel. Toutefois, ce n’est pas réellement une caméra autonome. Une fois que vous avez ajouté un viseur et une alimentation avec des batteries, vous obtenez une sorte d’appareil de bonne taille. Plus important, vous obtenez une latence élevée [Traduction incertaine] entre le capteur et le viseur. C’est pourquoi nous avons opté pour une carte mère basée sur une plate-fome TI qui inclue un écran LCD tactile.

Je ne saurais pas dire avec exactitude la part de code du projet Elphel qui permet à la Frankencamera de fonctionner, mais il est vrai que Stanford aurait pu faire un petit effort supplémentaire pour mettre en avant les travaux déjà réalisés par la société Elphel.

D’autant que d’un point de vue libération de code, comme je l’indiquai rien n’est encore disponible pour l’instant pour la Frankencamera. Coté Elphel les sources sont sur SourceForge et un wiki documente le tout.

Il s’agit néanmoins de deux projets assez différents bien qu’utilisant des composantes communes. L’université de Stanford travaille davantage sur un prototype d’appareil photo permettant accessoirement la capture de film vidéo. Le projet Elphel est avant tout une caméra vidéo réseau comme vous pouvez le voir sur la photo. Il s’agit ici du modèle NC353L-10369-HDD doté d’un disque dur interne de 1,8 pouces.

Elle dispose de plusieurs ports :

• Un port SATA pour connecter un autre disque externe
• Le port RJ45 100MBit apportant l’alimentation électrique grâce à la technologie POE (Power over Ethernet)
• un port USB 1.1

Elle peut être équipée de différents capteurs dont les résolutions vont de 5 à 16 Mpixel. Seul le capteur de 5 MPix permet de réaliser des films vidéo, la résolution des autres capteurs les destinant plus à de la prise de photo. Toujours avec ce capteur de 5MPix  les résolutions et nombre d’images capturées par seconde sont les suivantes :

• 15 fps @ pleine résolution (2592×1944),
• 30fps @ Full HD (1920×1080),
• 60 fps @ HD (1280×720).

A 30 fps en full HD on dispose déjà d’une très bonne qualité d’image.Vous ne serez donc pas étonné d’apprendre qu’un autre projet nommé “Apertus open source cinéma” ait vu le jour. Son objectif est de créer une caméra libre et ouverte destinée aux professionnels de l’image pour le tournage de films de cinéma

Article original écrit par Philippe Scoffoni le 11/09/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

[EDIT 13/09/2009] : Merci de prendre connaissance aussi de l’article concernant le projet Elphel de caméra aux spécifications ouvertes sur lequel le Frankencamera est basée en partie.

J’utilise depuis bientôt 4 ans un CANON Powershot S2 IS. Un appareil qui s’il n’est plus au top technologique continue de parfaitement répondre à mes besoins et surtout à mes capacités de photographe amateur.

Depuis un an il souffre d’un problème chronique : une forme de rhumatisme oculaire. A l’allumage, le diaphragme de l’objectif ne s’ouvre pas toujours. Il reste en quelque sorte coincé. Le contournement de ce défaut de vieillesse que j’ai trouvé sur un forum consiste à prendre une photo en réglant un temps de pose de l’ordre de 15 secondes. je déclenche la photo, je compte jusqu’à cinq… et j’enlève les piles ! Bien entendu, plus de photo sur le vif avec ce genre de manipulation.

En général au bout d’un ou deux manipulations de ce type, le diaphragme daigne s’ouvrir ce qui me permet de prendre à nouveau des photos. Ce n’est pas systématique, mais fréquent surtout après une longue période d’inutilisation.je me doute qu’un jour cela ne suffira plus et qu’il me faudra me résoudre à acheter un nouvel APN.

Il m’est souvent arrivé de me dire que tant qu’à changer j’aimerais le faire pour un appareil utilisant des technologies ouvertes :

• Un hardware aux spécifications placées sous licence Creative Commons BY-SA,
• un firmware (le logiciel qui pilote le matériel) open source

Et bien il existe !

Enfin presque, les spécialistes de l’imagerie numérique de l’Université de Stanford viennent de concevoir ce qui est probablement le premier appareil photo open source.

De quoi s’agit-il ?

Le Frankencamera, dont le nom fait référence au vilain Frankenstein, repose sur une base matérielle issue d’un Nokia N95, un objectif de chez Canon et une bonne dose d’ingéniosité pour assembler le tout. Effectivement, le résultat est au dire même de ces créateurs “moche” mais fonctionnel.

Ce n’est donc pas du côté du matériel qu’il nous faut rechercher “d’ouverture”, mais dans le logiciel. En effet, le Frankencamera est propulsé par un noyau Linux et l’ensemble du code utilisé pour exploiter l’appareil sera d’ici un an rendu public. Le but recherché est d’obtenir un système d’exploitation complet pour lequel il serait possible de télécharger des applications pour ajouter de nouvelles fonctions à son APN.

Pour Marc Levoy qui dirige ce projet, il s’agit de fournir à court terme une plate-forme de développement à bas coût disponible d’abord pour les organismes de recherche en traitement numérique de l’image. Son ambition est d’ouvrir la possibilité de développer des algorithmes capables d’indiquer à l’appareil photo quoi faire dans la microseconde qui suit en fonction des multiples informations disponibles sur la scène en cours de photographie.

Parmi les travaux en cours :

• la capacité d’élargir la prise en charge des différentes exposition d’une scène pour fournir une image disposant d’une exposition optimisée pour les différentes zones.
• l’utilisation de photo haute résolution faite durant la capture d’une vidéo. Cette image et les informations qu’elle contient sont ensuite utilisées pour améliorer le rendu du film vidéo
• une connectivité réseau afin de rendre l’ANP communiquant. On comprend alors mieux le choix d’un téléphone mobile comme base de développement.

Ce projet a reçu le support de nombreux sponsor comme Nokia, Adobe Systems, Kodak, et Hewlett-Packard.

Il va falloir patienter encore un peu avant de voir un appareil de ce type commercialisé au grand public. Mais ne sait-on jamais peut-être cela donnera-t-il des idées à d’autres acteurs du marché du numérique. Alors un GoogleAPN pour l’été prochain ?

D’ici là, j’espère que mon vieux S2 continuera de fonctionner sans faire trop de caprice.

Source image : © Stanford University

Article original écrit par Philippe Scoffoni le 04/09/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Voila un autre projet de voiture dont les spécifications sont ouvertes. Je vous avais déjà présenté un projet similaire de véhicule urbain OScar.

Ce véhicule a été conçu par les Université d’Oxford et de Cranfield en Angleterre. La société Riversimple projette de lancer la production de celui-ci. Les spécifications sont disponibles sur le wiki de la fondation 40 Fires.

40 Fires Foundation a pour objectif de permettre le développement de véhicules énergétiquement  efficace au bénéfice de l’ensemble de la planète. L’ensemble du site est placé sous une licence CC BY-NC. Pour les puristes, il ne s’agit donc pas d’un projet Libre à cause de la clause NC interdisant une utilisation commerciale.

Il s’agit d’un véhicule propulsé à l’aide de moteurs électriques dont l’énergie est produite à partir d’hydrogène. Sa taille est approximativement celui d’une Smart Fortwo. Elle pèse environ 350 Kg et peut atteindre une vitesse de 80Km/h avec une autonomie de 320Km. Autre particularité technique, les roues sont équipées chacune d’un moteur électrique.

Michelin travaille également sur un projet de moteur roue électrique sous la dénomination d’Active Wheel. Un concept qui permet de simplifier la conception des voitures et qui peut même s’adapter sur un véhicule thermique éliminant ainsi son moteur à essence.

Le mode de commercialisation est également original car Riversimple prévoit de louer la voiture pour une durée de 20 ans. Cette location incluant le “carburant”. Il faudra cependant quelques changements de mentalité pour permettre à nos contemporains d’envisager de garder un même véhicule durant aussi longtemps à moins que ce véhicule ne soit qu’à destination de collectivité locales souhaitant mettre en location un parc de véhicule urbain propre.

Riversimple travaille actuellement sur une dizaine de prototypes et espère trouver un partenariat avec une ville pour lancer ce véhicule et l’infrastructure de production d’hydrogène correspondante.

Cependant la voiture à hydrogène n’a plus forcément la cote compte tenu des infrastructures et de l’énergie nécessaires à sa production. De plus le président américain Obama vient de stopper les financements fédéraux au développement de la voiture à hydrogène. Il n’en reste pas moins que l’ouverture du projet permettra probablement son adaptation à d’autres sources de production d’électricité.

[Source]

Article original écrit par Philippe Scoffoni le 21/06/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

Bruce Schneier explique que la transparence offerte par le fait que le code source soit public est essentielle dans cet environnement. On peut citer d’autres exemples, comme les fameuses machines à voter, boîtes noires de la démocratie ( l’Irlande vient de mettre les siennes au rebut, faute de fiabilité), ou encore les mouchards annoncés dans le cadre de la loi Hadopi, qui peuvent mener à la coupure d’accès à Internet. Comme l’explique Bruce Schneier, à partir du moment où l’enjeu est important (élections, décisions de justice), il faut être sûr que le logiciel qui aide à la prise de décision soit transparent, et qu’on puisse le compiler soi-même pour être sûr que le code source qu’on analyse est bien celui qu’on exécute. Cela implique en substance que le logiciel en question soit libre.

Une machine à voter open source est-elle la garante de la transparence du vote ? Etudions un peu la question.

Si le code est ouvert il est effectivement facile de s’assurer qu’il fait bien ce qu’il censé faire. C’est un point positif. Maintenant ce code va être installé dans une machine à voter. Il faut donc aussi que la conception de cette machine à voter soit ouverte.

Il faut donc aller un cran plus loin dans la définition de la machine à voter. Elle doit utiliser un logiciel libre et sa conception matérielle doit être ouverte. Par cette énoncée on commence déjà à toucher les limites. Mais cependant cela existe, il y a par exemple l’OpenRISC 1000 un processeur aux spécifications libres.

On peut donc obtenir une machine à voter dont les spécifications logiciels et hardware sont libres.

Comment va-t-on garantir que les machines à voter construites selon ces spécifications y seront conformes ? Qui sera chargé de cette certification ? Ensuite en admettant que ce point soit aussi levé, il faudra s’assurer que la machine livrée au point de vote soit bien celle qui a été contrôlée et qu’elle n’a subie aucune altération.

Vient ensuite le moment d’entrer dans la machine à voter les données concernant le point de vote : la liste des électeurs, des candidats. Il faudra trouver une solution pour que cette opération ne permette pas d’introduire des données falsifiées ou tout autre programme susceptible  de modifier le programme officiel.

Tout ceci m’a l’air très compliqué pour ne remplacer qu’une simple urne et s’éviter la corvée du dépouillement. Cette procédure manuelle n’est pas sans faille non plus. Mais son contrôle est accessible à n’importe qui et pas seulement les informaticiens.

Richard Stallman s’était déclaré opposé au principe des machines à voter quelle soit libre ou pas :

La démocratie est trop importante pour y prendre des risques évitables. Si un système numérique de comptage des voix paraît solide, il faudrait vingt ans d’expérience pour y faire confiance.

Tout cela pour montrer que dans ce cas précis, la transparence de l’open source ne régle pas forcément tous les problèmes. Bien sur cela parait bien mieux qu’une machine à voter propriétaire. Mais en l’occurrence  cela ne change au final que peu de choses. La question étant plutôt : avons-nous vraiment besoin d’une machine à voter ?

photo credit: John of Lebanon

Article original écrit par Philippe Scoffoni le 20/05/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).

En effet les opérateurs ne communiquent pas ces informations. Il faut donc utiliser des bases de données payantes.

Avec OpenCelliD, tout le monde peut créer ou utiliser une application pour collecter les données sur les cellules en utilisant par exemple un smartphone doté d’un GPS puis les envoyer au serveur OpenCellID. La base de données peut ensuite être utilisée par n’importe qu’elle application pour récupérer la localisation d’une cellule. Les données sont disponibles sous une licence “Creative Common Attribution-Share Alike 3.0 Unported”

Le code source de l’application est également disponible sur Google Code.

Ce projet a été initié il y a un peu plus d’un an par la société 8Motions. A noter que 8Motions malgré un site en anglais est une société française basée à Lormont (33).

A ce jour la base recense 300 000 cellules.

Un bel exemple d’effort collaboratif gagnant-gagnant qui au final permet à une société comme 8Motions de disposer d’une base de données pour un coût très faible.

Pour en savoir un peu plus sur la mise en oeuvre et l’utilisation de cette base de données vous pouvez vous reporter à cette série de deux articles (en anglais).

Crédit Photo page d’accueil

Article original écrit par Philippe Scoffoni le 29/04/2009. | Lien direct vers cet article

Cette création est mise à disposition sous un contrat Creative Commons BY à l'exception des images qui l'illustrent (celles-ci demeurent placées sous leur mention légale d'origine).