Blog - Pierre-Yves Gibello

Aller au contenu | Aller au menu | Aller à la recherche

mardi, février 12 2019

Wifi linux sur laptop HP 15-ba008nf (carte realtek / Ubuntu 18.04)

NOTE: CE TUTO EST RENDU OBSOLETE PAR UBUNTU 20.04

Les drivers RealTek sont maintenant intégrés au noyau, et l'ancien repo Git avec le code source a disparu. Il faut donc upgrader son système !

En cas de souci sur la 20.04+ avec une ancienne installation (les exemples ci-dessous se réfèrent à ma carte rtl8723be, voir plus bas dans l'ancien tuto comment détecter le modèle de la votre, et remplacer "rtl8723be" par la bonne valeur dans les commandes):
- Supprimer l'ancienne configuration, s'il y en a une. Exemple:
$ sudo mv /etc/modprobe.d/rtl8723be.conf /tmp
- Recharger le driver. Exemple:
$ sudo modprobe -r rtl8723be
$ sudo modprobe rtl8723be

Ci-dessous, l'ancien article, au cas où... Certains conseils de configuration peuvent encore servir !
===========================================================

Heureux propriétaire d'un beau PC portable HP 15-ba008nf, j'y ai installé un Linux Ubuntu 18.04.

Tout allait bien jusqu'à ce que j'essaie de me connecter au Wifi : impossible ! Et comme c'est une vraie galère (pour faire court : la carte RealTek du PC n'est pas supportée par défaut dans le système, donc vous pouvez toujours batailler), ci-dessous la solution :

D'abord, s'assurer que le "secure boot" est désactivé (dans la configuration du BIOS : chercher de la doc sur le web). Pas certain que ce soit nécessaire, en fait, mais on le conseille partout si problème de Wifi, alors pas besoin de se compliquer encore la vie.

Ensuite, vérifier quelle carte on a :
lspci -nn | grep -i net

Sur mon HP 15-ba008nf, çà retourne :

02:00.0 Network controller 0280: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter 10ec:b723
03:00.0 Ethernet controller 0200: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller 10ec:8136 (rev 07)

La carte wifi est donc une RealTek RTL8723BE .

Il faut installer les modules à la main (il y a plein de modules Realtek, donc si votre carte est plutôt une rtl8192ce ou rtl8821ae par exemple, çà risque de marcher aussi... remplacer le nom du module, dans les commandes ci-dessous, par le votre).

D'abord, installer l'environnement de dev :
sudo apt-get install git
sudo apt-get install linux-headers-generic build-essential dkms git

Ensuite, télécharger et compiler/installer les modules :
git clone https://github.com/lwfinger/rtlwifi_new.git
cd rtlwifi_new/
make all
sudo make install

Enfin, charger le module dans le système :
sudo modprobe rtl8723be

A partir de là, çà doit marcher !
Si çà rame (faible débit), il faut sélectionner la bonne antenne (il y en a 2).

Pour essayer l'antenne 2, par exemple :
sudo modprobe -r rtl8723be
sudo modprobe rtl8723be ant_sel=2
(note : ant_sel=1 pour la 1, toujours faire "modprobe -r" avant pour supprimer le module).

Et si çà va plus vite, conserver la configuration. Exemple, pour l'antenne 2 :
echo "options rtl8723be ant_sel=2" | sudo tee -a /etc/modprobe.d/rtl8723be.conf

Voilà... Facile, non ?

mercredi, mai 16 2012

Comment gmail te fiche... même sans compte !

Comme les exemples concrets valent tous les discours, imaginons un petit cas d'école :

Suite à votre installation dans une nouvelle maison, vous invitez votre ami Gérard Lambert à un barbecue. Comme c'est un fidèle utilisateur de gmail, vous envoyez ce genre de message à gerard.lambert@gmail.com :

"Salut Gérard,

Comme tu ne connais pas encore notre nouvelle maison, on t'invite à un barbecue, samedi midi.

L'adresse : ...

Evidemment, tu peux venir avec ton fils, ainsi que ta compagne et sa fille, ce sera avec plaisir.

etc..."

Et là, vous avez un problème. Que sait google ?

  • Il a votre email
  • Il sait que vous êtes l'ami de Gérard Lambert
  • Il sait que vous avez une maison et que vous organisez des barbecues
  • Il a votre adresse, et avec Google Earth, la photo de votre parcelle
  • Il sait que Gérard a une famille recomposée (un fils + une compagne avec une fille).

Sans doute sait-il même plein d'autres choses, en croisant les infos ci-dessus avec ce qu'il y a déjà dans la boîte mail de Gérard et dans celles de ses contacts disposant de comptes gmail (sans compter le réseau social google+, voire même le suivi de liens externes sur internet afin de cibler qui sont les protagonistes... Disons qu'il ne doit pas lui être très difficile de cibler votre catégorie socio-professionnelle, entre autres !)

Au passage, google sait aussi quel jour et à quelle heure Gérard et vous-même vous trouverez dans le jardin (et tient ces informations à disposition des services américains, au cas où, et au nom du "patriot act" ou de ne je ne sais quelle Busherie du même genre - les dits services pouvant croiser tout çà avec l'historique de vos voyages aériens, entre autres, mais là, je m'éloigne du sujet).

Et tout çà... sans même que vous n'ayez de compte gmail, puisque vous êtes attentif à l'aspect privé de vos données personnelles (enfin, vous croyez l'être...)

Eh bien, je parie qu'il y a quelques irakiens qui se sont pris un missile sur la tête pour moins que çà : des fois que la NSA trouverait mes propos trop subversifs, je crois bien que je vais changer à la dernière minute l'heure de mon prochain barbecue !

Moralité : si ce message ne suffit pas à vous convaincre de transférer votre gmail chez un hébergeur perdu du Cantal, tâchez au moins de le bourrer d'informations stupides, contradictoires, fausses, lourdes et inutiles, çà sera toujours mieux que rien...

vendredi, février 3 2012

Un mini serveur web en java 7

Le JDK 7 fournit une API intégrée à JAX-WS, qui permet de servir facilement du contenu web en http, sans rien d'autre qu'une JRE java7.

Le principal intérêt de ce genre d'approche étant la possibilité d'exposer en HTTP les fonctions d'un programme java, sans avoir à installer autre chose que la JRE (pas besoin de serveur d'application, etc...) : la méthode est par contre inadaptée aux contextes de forte montée en charge !

L'exemple de code ci-dessous est un mini serveur web : pour l'adapter, il suffit de changer l'URL et le chemin du fichier à servir. A ceci près, il compile et fonctionne parfaitement !
Compilation : javac WebServer.java
Exécution java WebServer (et contactez l'URL http://localhost:1234/hello avec votre navigateur).

// WebServer.java

import javax.activation.DataSource;
import javax.activation.FileDataSource;
import javax.activation.MimetypesFileTypeMap;

import javax.xml.ws.Endpoint;
import javax.xml.ws.Provider;
import javax.xml.ws.Service.Mode;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceProvider;
import javax.xml.ws.http.HTTPBinding;

public class WebServer {

  public static void main(String args[]) {
    Endpoint endpoint = Endpoint.create(
      HTTPBinding.HTTP_BINDING, new HtmlFileProvider());
    System.out.println("Starting web server at http://localhost:1234/hello");
    endpoint.publish("http://localhost:1234/hello");
  }

}

@WebServiceProvider
@ServiceMode(Mode.MESSAGE)
class HtmlFileProvider implements Provider {

  @Override
  public DataSource invoke(DataSource request) {

    // Change path below to serve your own HTML file...
    FileDataSource fds = new FileDataSource("/var/www/index.html");

    MimetypesFileTypeMap ftm = new MimetypesFileTypeMap();
    ftm.addMimeTypes("text/html html htm" );
    fds.setFileTypeMap(ftm);
    return fds;
  }

}

jeudi, janvier 5 2012

Génie logiciel : comment tirer parti de l'intelligence ambiante ?

Après avoir pas mal traîné mes guêtres dans le monde de l'IT et de l'intergiciel (ou "middleware"), j'ai presque tout entendu sur les mérites réels ou supposés de telle ou telle architecture innovante (de Corba au "cloud computing" en passant par les serveurs d'application, la SOA, etc... et j'en passe !). Au final et à de rares exceptions près, la déception est généralement à la mesure de la grandeur que l'on prête au concept... le succès étant souvent le fait d'outsiders inattendus (TCP/IP et les protocoles de l'internet, REST, les mashups...), ayant pour trait commun une relative absence de finalité et d'organisation, qui est la marque des systèmes dont l'existence précède les usages.

Je vais donc m'essayer à jeter en vrac quelques principes et/ou "patterns" de nature à caractériser les conditions de succès ou d'échec en matière d'architecture logicielle :

1) Diviser pour régner, ou le bon usage du "micro-pattern"
Toute fonction d'un logiciel qui peut être isolée comme principe général (un parser, un système de log, un moniteur transactionnel, un framework MVC, un widget, un conteneur de composants...) doit être externalisée sous forme de composant indépendant.
Dans l'idéal, cette brique de base doit être proposée sous une licence permettant le "fork" (que ses utilisateurs cibles puissent la réutiliser et la modifier s'il le faut pour l'adapter à leurs besoins) - si l'open-source est envisagé, une licence style BSD paraît de bon aloi (la GPL peut également convenir sous certaines conditions, notamment pour bloquer ou contrôler la privatisation éventuelle du code).
Cette approche est particulièrement compatible avec les systèmes de gestion de version modernes, et notamment GIT (où le fork de projet est un concept central).
Et elle permet d'assembler des logiciels incroyablement efficaces en un minimum de temps !

2) Etre aussi neutre que possible
Ce point rejoint en partie le précédent : à savoir, un système bien conçu se contente de faire ce à quoi il sert, et n'introduit pas d'autre contrainte (la fameuse "neutralité du net", qui ne fait que transporter des paquets sans discernement, en est une bonne illustration).
Ce point est un facteur clé d'ouverture à l'innovation future (plus vous introduisez de contraintes, plus les futurs innovateurs seront empêtrés dedans). "La loi ne peut interdire que ce qui nuit à autrui", dit la Déclaration des Droits de l'Homme (que l'architecte logiciel ferait bien de lire).

3) S'appuyer sur ce qui est éprouvé
Ce point rejoint une définition désormais fameuse de la stabilité d'un composant (est stable ce qui est utilisé fréquemment), et vient l'élargir (à d'autres domaines comme la montée en charge, la performance, la sécurité, etc...)
Pour un architecte logiciel, çà peut être très pragmatique : les "file system", bases de données, serveurs d'application, machines virtuelles... les plus utilisés ont tellement été optimisés à travers les âges qu'il devient quasiment impossible de les battre sur leur terrain.
Autrement dit, l'utilisation basique de ces systèmes a toute chance d'être préférable à la plus intelligente des constructions architecturales. Tant pis pour le côté glamour ou l'orgueil de l'architecte !

4) Détruire presque autant de code qu'on en produit
Autrement dit, moins j'ai de code, mieux je me porte : refactoring permanent (tant pis si vous jetez 3 semaines de boulot parce que vous avez inventé plus simple, au contraire !), et tout faire pour ne pas accumuler de "dette technique" (coder "avec les pieds" en se disant qu'on améliorera çà plus tard est une très mauvaise idée, largement pire que ne pas coder du tout).

5) Aller vite par cycles courts + feedback
Développez quelque chose, mettez-le à disposition, et réparez ce qui ne marche pas (ou laissez les autres le réparer s'ils vont plus vite). C'est vieux comme le monde, même si les méthodes "agiles" (scrum et autres XP) se la jouent moderne. Et çà a toujours fonctionné !

6) L'intéropérabilité n'existe pas, mais l'intelligence ambiante, si !
Ou "de la supériorité du mashup sur tout autre mode d'intégration" (n'allez jamais croire en la moindre technologie d' "interopérabilité" : on la promet depuis qu'on a inventé l'ordinateur à lampes).
Imaginez que quelqu'un veuille réutiliser un composant ou un service que vous fournissez : il devra au préalable comprendre votre métier (sinon il le réutilisera de travers). Ensuite, il saura bien s'adapter aux interfaces, APIs et autres documentations que vous lui fournirez, afin d'intégrer son système au votre. Inutile, donc, de vouloir imposer tel ou tel standard : fournissez une interface proche du métier, documentez-là, et faites confiance à l'intelligence de ceux qui en feront usage (ou des systèmes qu'ils développent).
Au pire, fournissez simplement les données, et que les usagers fassent avec !
C'est la force des APIs de "mashup" fournies par les Facebook, Google Maps, etc..., voire de l'"open-data" : on se débrouille bien mieux avec çà qu'avec tout système auto-descriptif prétendument "standard".

7) Faire confiance à l'humain
Coder, c'est créer. Les langages de programmation ou les protocoles d'intégration sont des grammaires et des syntaxes, comme les langues ou les systèmes formels mathématiques.
Ici aussi, il est question de style et d'élégance : comme pour un écrivain ou un mathématicien. Donc, inutile d'édicter des règles de pseudo-"qualité logicielle" contrôlées par force métriques et outils de validation (forcer Proust à écrire en alexandrins eût certainement été désastreux). Ca marche toujours moins bien qu'une gestion intelligente et attentive du bordel ambiant !

8) Coder !
Dans le futur monde connecté, celui qui ne saura pas coder ne saura ni lire, ni écrire. Vous n'avez sûrement pas besoin du dernier générateur de code à la mode avec des wizards partout, lequel a toutes chances de produire un galimatias incontrôlable. Ou si vous en avez vraiment besoin, demandez-vous 7 fois pourquoi, avant de l'utiliser !
Par contre, vous avez besoin d'une puissance d'expression qui soit la moins limitée possible : a minima, celle que fournit un langage de programmation dit "turing complet" (sinon celle que la langue fournit à la littérature). Apprenez donc à programmer, sinon vous ne saurez pas vous exprimer.

Bref, rien de neuf qui dépasse le bon sens paysan !

lundi, novembre 23 2009

L'intéropérabilité pour les nuls...

L'intéropérabilité, c'est la capacité qu'ont différents systèmes d'intéragir (inter-opérer, çà dit son nom), d'échanger, de fonctionner et travailler ensemble.
Le problème, généralisable, est particulièrement critique dans le domaine des technologies de l'information.

Et comment obtient-on l'intéropérabilité ? Eh bien, il y a au moins deux méthodes : l'uniformisation du monde, ou l'adoption de standards ouverts.

La première méthode est simple : tout le monde utilise le même logiciel, protocole, format, etc... Les mauvaises langues diront que ce n'est pas de l'intér-opérabilité mais de la "self"-opérabilité : certes. Mais la méthode a d'autres travers : outre une certaine fragilité (cf. la biodiversité : plus elle est réduite, plus une attaque risque de détruire tout l'écosystème) et le risque d'appropriation par une firme privée ou un lobby, elle nécessite sutout une uniformisation de la culture et des pratiques, laquelle ne peut être obtenue que par un contrôle strict et régalien, assorti de sanctions fermes.

Autrement dit, la "self-opérabilité" ne peut être obtenue que par la dictature.

A l'opposé, les standards ouverts garantissent que les données et les protocoles, publics et d'accès libre, peuvent être mis en oeuvre, exploités ou étudiés par tous (ce qui favorise, au passage, l'accès de tous au savoir, ainsi que les logiciels open-source).
Leur évolution ne peut se faire que de manière collégiale, via des structures démocratiques prenant en compte l'avis des utilisateurs et de toute personne ou organisation intéressée.

Autrement dit, les standards ouverts, c'est une forme de démocratie décentralisée (leur établissement étant le fait, par exemple, de consortiums, organismes publics ou associations à processus de décision ouvert).

De récents travaux financés par l'Europe font état de voies intermédiaires : il existerait un "continuum" entre l'ouverture totale et la fermeture totale, au long duquel il serait légitime de se positionner (cf. un récent article de Glyn Moody sur ComputerWorld UK, que j'ai accessoirement traduit en français ici, et qui détaille les croustillants travaux de l'IDABC).

C'est presque aussi absurde que de déclarer qu'il existerait un "continuum" entre la dictature et la démocratie au long duquel les états devraient se positionner, mais passons... En ce qui concerne l'intéropérabilité, se positionner librement entre l'ouverture et la fermeture, çà revient à entériner le système actuel, lequel est tout sauf intéropérable, justement parce que chacun fait un choix différent du voisin.

Ce qui démontre que l'intéropérabilité est impossible sans une forme de "contrôle politique" : ou, pour parler comme un économiste, qu'il n'y a pas de "main invisible" qui ferait tendre le système vers l'intéropérabilité.

Et le "contrôle politique", ici comme ailleurs, c'est soit la dictature, soit la démocratie. Camarade, choisis ton camp...


P.S. Cette réflexion a été nourrie par une analyse économique de Jacques Sapir, à propos de la théorie de l'équilibre général de Walras, dont il démontre qu'elle ne peut s'appliquer réellement sans un contrôle politique, de forme soit totalitaire, soit démocratique, mais proche de ceux décrits ici : cf. "Les trous noirs de la science économique : essai sur l'impossibilité de penser le temps et l'argent" (Seuil / points économie, 2003)

mercredi, juillet 29 2009

Exposer un bundle OSGi sous forme de Web Service

Réalisé avec les projets Apache Felix (plateforme OSGi, felix.apache.org) et CXF (web services, etc...)...
Evidemment, ce post, valable le jour où il a été posté, devrait se périmer assez vite (en particulier en ce qui concerne les versions des outils utilisés, et leur localisation).

Le principe pourrait toutefois ne pas changer trop vite :

  • * Tout d'abord, installer puis démarrez le bundle d'extension "OSGi compendium API's", fourni avec Felix comme sous-projet (téléchargeable ici).
  • * Ensuite, installez puis démarrez le bundle OSGi CXF (cxf-dosgi-ri-singlebundle-distribution-1.1-SNAPSHOT.jar, à télécharger ici).
  • * Enfin, avant d'être installé/démarré, Le bundle OSGi que vous souhaitez exporter doit être spécifiquement "annoté" (en fait, des Properties à associer à l'enregistrement de l'interface, dans l'Activator). Ce qui permettra au bundle Apache CXF de le détecter au moment du "start", et de l'exporter sous forme de Web Service !

Donc, dans le détail :

1) Ecrire un bundle OSGi - ici, un "HelloWorld" qui exporte l'interface suivante :

package helloworld;
public interface HelloService {
  public String sayHello(String name);
}

Le bundle se compose de 3 fichiers :

- L'interface : HelloService.java

package helloworld;
public interface HelloService {
  public String sayHello(String name);
}


- L'activateur Activator.java : tout simple, mais notez les 3 lignes "props.put" (+ le passage de "props" en paramètre de registerService()) qui concernent l'exportation de l'interface sous forme de Web Service, et qui permettront au bundle CXF d'enregistrer le nouveau bundle comme web service dès qu'il sera détecté au démarrage :

package helloworld;

import java.util.Dictionary;
import java.util.Hashtable;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceListener;
import org.osgi.framework.ServiceEvent;

public class Activator implements BundleActivator {
  public void start(BundleContext context) {
    Dictionary props = new Hashtable();

    props.put("service.exported.interfaces", "*");
    props.put("service.exported.configs", "org.apache.cxf.ws");
    props.put("org.apache.cxf.ws.httpservice.context", "/helloworld");

    context.registerService(HelloService.class.getName(), new HelloImpl(), props);
 }

  public void stop(BundleContext context) { }

  /**
   * Implementation de l'interface HelloService
   */
  private static class HelloImpl implements HelloService {
    public String sayHello(String name) { return "Hello " + name + "!"; }
  }
}

- Le manifeste, manifest.mf :

Bundle-Name: HelloWorld
Bundle-Description: A Hello World bundle
Bundle-Vendor: Gibello
Bundle-Version: 1.0.0
Bundle-Activator: helloworld.Activator
Export-Package: helloworld
Import-Package: org.osgi.framework


Reste ensuite à créer le bundle (au préalable, faire pointer le CLASSPATH vers la librairie felix.jar - qui contient les classes d'OSGi, et se trouve dans le répertoire bin/ de felix) :

javac -d . *.java
jar cfm helloworld.jar manifest.mf helloworld/

2) Installer et démarrer les 3 bundles dans Felix :

Supposons que les 3 bundles (org.osgi.compendium-1.2.0.jar, cxf-dosgi-ri-singlebundle-distribution-1.1-SNAPSHOT.jar et helloworld.jar) soient copiés dans un sous-répertoire "my_bundles" du répertoire de felix :

  • * Démarrer Felix ( java -jar bin/felix.jar )
  • * Installer / démarrer les bundles (install ... start)
$ java -jar bin/felix.jar 

Welcome to Felix.
=================

->
-> install file:my_bundles/org.osgi.compendium-1.2.0.jar
Bundle ID: 25
-> start 25
->
-> install file:my_bundles/cxf-dosgi-ri-singlebundle-distribution-1.1-SNAPSHOT.jar
Bundle ID: 26
-> start 26
->
-> install file:my_bundles/helloworld.jar
Bundle ID: 27
-> start 27
->

3) Le web service est prêt...

Maintenant, il ne reste donc qu'à accéder au Web Service !
Par exemple, pour accéder à sa description WSDL :

http://localhost:8080/helloworld?wsdl

A noter qu'il est parfaitement possible de générer des "stubs" java pour y accéder, par exemple avec l'outil wsimport du JDK (à partir de la version 1.6) - le web service semble donc compatible avec JAX-WS.

lundi, mai 11 2009

Un peu de recul sur Hadopi...

Laissons un peu de côté le tumulte ambiant, et posons nous la vraie question : Hadopi, c'est quoi ?

Hadopi est une loi sur la technique.

Elle vise à réglementer la manière dont une technique (l'échange de fichiers, pour simplifier) doit se propager dans la société, et ce que doit être son contenu.

En ceci, elle est assimilable à toute loi sur la technique : par exemple, lorsqu'il s'agit de réglementer les OGM, ou le déploiement des antennes-relais, ou la spéculation financière, le problème est exactement identique.

Autrement dit, légiférer sur la technique est indépendant du contenu : et ceci est dû à certaines propriétés de la technique, par ailleurs bien connues, au moins depuis les années 60 (à ce sujet, on s'intéressera, par exemple, aux travaux de Jacques Ellul ou de Marshall McLuhan, entre autres).

Tout d'abord, la technique n'est pas neutre : autrement dit, pour revenir à Hadopi, ce que deviendra l'échange de fichiers ne dépend pas de "ce qu'on en fera", mais ne dépend que de deux paramètres : la nature propre de cette technique, et la nature de l'homme social (ou, dit encore autrement, la manière dont l'échange de fichiers modifiera la société ne dépend pas de notre volonté).

Ensuite, la technique n'est pas "bonne ou "mauvaise" : échanger des fichiers, ce n'est pas "bien" ni "mal" (et pas davantage "moral" ou "immoral"). L'introduction d'une technique peut modifier la société dans un sens plus ou moins bénéfique (ou négatif), mais là encore, c'est indépendant de notre volonté.

Enfin, les effets de la technique ne sont connus que beaucoup plus tard, longtemps après son introduction, essentiellement pour deux raisons : les délais de diffusion profonde de la technique et de ses conséquences, et un certain état de fascination de l'homme (lequel baigne dans un environnement nouveau dont il fait partie, ce qui interdit tout recul) dont la technique induit ensuite de nouveaux comportements (inconnus au départ).
La technique nous transforme autant que nous la transformons, et ce processus prend du temps.

Autrement dit, légiférer sur une nouvelle technique revient à légiférer sur l'inconnu, ce qui ne peut avoir que des effets aléatoires à court terme, puis négligeables à long terme (la loi n'ayant que peu de chances d'être axée sur les bonnes problématiques, encore inconnues au moment où elle est votée).

Ce constat ne peut que rendre divertissant le débat sur Hadopi : quoique racontent ses défenseurs ou ses opposants (et qui tient généralement de la brève de comptoir), et quelle que soit la teneur du texte voté, çà ne changera rien sur le fond, et ceci tient aux propriétés générales de la technique.

Ce qui fait moins rire, c'est que la même conclusion s'applique à toute velleité de réglementer la technique : les OGM ou le nucléaire existent, fort bien, on sait qu'on devra faire avec, applications militaires incluses (n'en déplaise à nos députés et gouvernants, lesquels, au passage, n'y connaissent rien - pas plus que pour Hadopi, et probablement moins - mais "heureusement", on l'a vu, ce détail importe peu, puisque leur pouvoir est inexistant).

Bon, mais revenons à Hadopi.

Il se peut que cette loi ait des effets à court terme : effets aléatoires, on l'a vu. Elle peut ralentir l'échange de fichiers ou l'accélérer, précipiter la fin des majors ou la freiner, faire condamner quelques grand-mères ou quelques vrais "pirates", ou n'être jamais appliquée ni applicable... mais nul ne peut dire ce qui adviendra.

La seule chose dont on est certain, c'est qu'à long terme, Hadopi ne changera rien. Reste à espérer que les mutations sociales liées à l'échange de fichiers nous conduiront dans une direction souhaitable : "le hasard fait bien les choses", dit la sagesse populaire...

mercredi, juin 18 2008

Echanges avec Eben Moglen à propos des licences GPL

Retour sur une sympathique entrevue avec Eben Moglen, organisée à l'initiative de la communauté open-source OW2 (dont je suis membre actif)...

Pour ceux qui ne connaissent pas Eben, c'est tout simplement l'avocat de la FSF (Free Software Foundation), l'auteur des licences GNU (dont la fameuse GPL), et sans doute le premier juriste à avoir traduit en termes légaux la notion de "copyleft" (il n'a pas inventé le copyleft... mais lui a donné la validité juridique qui lui manquait !). Il enseigne aussi le droit à l'Université de Columbia (New York).
Eben est également un homme de conviction, et développe une analyse marxiste de l'évolution de la propriété intellectuelle (selon lui, une nouvelle "lutte des classes" oppose les travailleurs de la connaissance aux tenants de la propriété intellectuelle "classique", que le sens de l'histoire devra faire tomber, comme il a fait tomber la propriété féodale au moment de la Révolution française... La propriété intellectuelle étant perçue comme une des bases du système économique, son raisonnement prend alors une portée générale).

Bref, à mon sens, Eben est l'un des juristes les plus importants des 30 dernières années... Mais revenons à notre thème central : nous sommes ici pour questionner Eben sur la licence GPL (en particulier, la nouvelle GPL v3, mais plus globalement ce qu'implique l'utilisation de la famille de licences GPL).

Rappel pour les non initiés : la GPL (General Public License) met en oeuvre le principe du "copyleft" (jeu de mot intraduisible, qui suggère le contraire du droit d'auteur - "left" signifie "gauche" alors que le "right" de "copyright" signifie "droite" - mais aussi le fait de laisser le droit à quiconque de copier : "copy left" signifie, en gros, "je laisse copier qui veut").

Le copyright permettait à un auteur de restreindre les droits sur son oeuvre (droits d'utilisation, de distribution, de modification...). Le copyleft, c'est l'inverse : l'auteur interdit à quiconque toute restriction des droits (et laisse généralement, au départ, toute liberté de copie, distribution ou modification).

La GPL met en oeuvre le "copyleft" de façon virale : non seulement les droits ne peuvent être restreints sur l'oeuvre originale, mais également sur toute oeuvre dérivée (forcément couverte par la même GPL). Elle garantit que toute oeuvre libre, même modifiée, le restera...

Et notre réunion ? Eh bien, elle se déroule à Paris (le 5 juin dernier), en présence d'une dizaine de personnes, dont j'ai la joie de faire partie. Je me suis spécialement déplacé pour l'occasion : 2 heures de questions libres à Eben Moglen, comment résister ?

Compte-rendu, dans la limite de ce que je peux comprendre (je ne suis pas juriste, et dispose d'un anglais acceptable... sans plus !) :

Tout d'abord, Eben a fait quelques rappels simples sur la GPL : en ce qui concerne les oeuvres dérivées, il est clair que les modifications privées peuvent rester privées (usage interne, par exemple - ou toute modification qui n'est pas diffusée)... mais toute version distribuée doit être couverte par la GPL, qui est bien en ce sens une licence virale.

La GPL v3 définit plus clairement ce qu'est une copie "privée" (non couverte par la GPL car non redistribuée) : il est maintenant clair que la sous-traitance reste dans le cadre privé. Exemple : si une SSII travaille pour vous, sous contrat, sur du code GPL que vous ne redistribuez pas... le fait de le transmettre à cette SSII n'est pas une distribution, donc ce n'est pas couvert par la GPL !

J'ai pu poser à Eben une question qui me taraude depuis longtemps : à savoir, quel est le périmètre exact d'une "oeuvre dérivée" ? Par exemple, une application de gestion qui utilise la base de données MySQL (couverte par la GPL) ne saurait être considérée comme une "oeuvre dérivée" de MySQL... mais où est la limite ?

J'ai pris un exemple plus tangent : une servlet déployée dans un conteneur couvert par la GPL... Réponse d'Eben : dans la mesure où les 2 programmes peuvent fonctionner indépendamment (dans le cas de ma servlet, çà implique qu'il existe au moins un second conteneur compatible dans lequel je puisse la déployer), ET à condition qu'une interface publique d'échange soit utilisée (ma servlet utilise l'API servlet, qui est publique), alors on n'est pas en présence d'une oeuvre dérivée.
Donc, même si l'interface d'un composant GPL est publique, encore faut-il que le composant qui fournit cette interface soit interchangeable... sinon, tout programme qui l'utilise est une oeuvre dérivée !
A noter que la GPL v3 éclaircit les choses, dans ce domaine (sous GPL v2, toute distribution commune de 2 oeuvres était considérée comme une seule oeuvre composite, même si l'oeuvre n'était pas à proprement parler "dérivée" - ce n'est heureusement plus le cas). Pour les servlets, on est donc tranquilles... mais il faut quand même se méfier !

Eben a ensuite tempéré ce propos en rappelant que, si je suis l'auteur d'un programme, c'est moi qui fixe les droits : je peux très bien fournir une interface publique, et décréter que les programmes qui utilisent cette interface ne sont pas des oeuvres dérivées du programme initial. Il parait même que Linus Torvalds a utilisé ce moyen pour certaines interfaces du noyau Linux !

Sinon, retour sur quelques caractéristiques spécifiques à la GPL v3, d'après ce que j'ai pu comprendre...

La GPL v3 se veut "transnationale", c'est-à-dire détachée de tout contexte juridique local (entendez "moins liée au droit américain que la v2"). Pour celà, elle utilise un vocabulaire le moins connoté possible (décorrélé du domaine juridique).

Le droit central qu'octroie la GPL, c'est le droit de distribuer une oeuvre dérivée : la GPL v3 établit clairement que des oeuvres dérivées peuvent être librement redistribuées, et que ce ne sera pas criminel quelle que soit la juridiction.

La GPL v3 offre aussi des garanties nouvelles, au moins dans 2 domaines :
- La "tivoization" (= le fait de faire en sorte qu'un logiciel ne puisse fonctionner que sur une plateforme hardware donnée) : sous GPL v3, toute oeuvre dérivée adaptée à un hardware spécifique doit être distribuée avec le mode d'emploi pour l'installer.
- Les brevets : l'auteur ne peut défendre aucun brevet sur le code original (et le principe vaut aussi pour les contributeurs, concernant les oeuvres dérivées). Si brevet il y a, les utilisateurs / distributeurs / contributeurs du code ne peuvent être inquiétés à ce titre.

Enfin, questionné sur la validité éventuelle de "restrictions à l'exportation" pour un programme couvert par la GPL, Eben est catégorique : c'est impossible. Raison invoquée à titre d'exemple : "Microsoft est assez riche pour s'acheter un petit état" ! CQFD...

Si, globalement, la discussion est restée assez technique (quoique rendue vivante par quelques exemples et anecdotes), Eben n'a pu totalement s'empêcher d'aborder le volet "idéologique" :
Lorsqu'une communauté publie du code sous GPL, il devient très difficile de prendre le contrôle de cette communauté (de la racheter, par exemple...). L'utilisateur se trouve alors en présence d'une chaîne d'approvisionnement "sans but lucratif" (littéralement "non profit supply chain"), qu'il est nécessaire de protéger comme tout bien commun devrait l'être : Eben a pris pour exemple la forêt, ou, avec malice, nos marins-pêcheurs...

Voilà, j'arrête là... en espérant que ce compte-rendu puisse être utile, et que je n'ai pas trop déformé les propos d'Eben (en les comprenant mal ou en les traduisant). En tout cas, j'ai maintenant les idées plus claires, et j'espère que vous aussi !

Un grand merci, bien sûr, à Eben Moglen pour sa patience et sa disponibilité.

mercredi, mai 28 2008

Le "piratage", épouvantail des conservateurs

Ces derniers temps, le législateur prend à nouveau de grands airs offusqués à propos d'un sujet cent fois rebattu : le "piratage" sur Internet, et particulièrement sa forme la plus subversive, le "peer to peer" ou échange de fichiers (les échos de la polémique emplissent le web français et même européen : il y est question de la loi "HADOPI" ou "loi Olivennes", de "riposte graduée" avec amendes et fermeture administrative des connexions internet de contrevenants, et autres fariboles néo-fascistes à base d'écoutes privées conduites par de zélés fonctionnaires... semblant tout droits sortis d'un passé aux relents douteux).

Mais bon, le but de ce post n'est pas d'enfler la polémique ambiante, ni de rabâcher des informations déjà cent fois publiées : les chiens aboient, la caravane passe.

Il s'agit plutôt, ici, de faire un tour d'horizon de ce qu'est réellement le "piratage", souvent présenté comme un vol pur et simple par les uns, et comme une sorte de droit inaliénable par les autres... panorama des principaux concepts et enjeux sous-jacents.

La notion de "ressource rivale"

Une ressource est dite "rivale" si sa possession par quelqu'un empêche sa possession par quelqu'un d'autre (sinon, elle est dite "non rivale").
Ma voiture est une ressource "rivale" (si vous la prenez, je n'en ai plus), tout comme un disque sur l'étal d'un disquaire (si je le subtilise, le disquaire ne l'a plus).
A contrario, une idée, par exemple, est une ressource "non rivale" (si je vous fais part de l'idée, nous sommes deux à la détenir : je n'en suis pas dépossédé). Il en va de même d'un morceau de musique enregistré : si j'en détiens une copie, celui qui détient l'original l'a toujours !
Toute la roublardise de ceux qui assimilent le piratage au vol consiste à confondre ressources "rivales" et "non-rivales" : vous qui ne voleriez pas un disque, vous le copiez, c'est pareil ! Cet amalgame relève évidemment de la mauvaise foi.

La notion de coût marginal

Important en économie, le "coût marginal" d'un bien ou d'un service est son coût réel de production à l'instant T.
Par exemple, si un constructeur automobile conçoit un nouveau modèle et construit une nouvelle usine pour le produire, il devra amortir ses investissements : le coût de production des premiers exemplaires sera élevé.
Mais si le succès est au rendez-vous, une fois ces coûts amortis, produire une voiture ne coûtera plus que le prix des pièces, de la main d'oeuvre, plus une fraction du coût de fonctionnement de l'usine.
Pour une voiture, ce sont quelques milliers d'EUR. Pour un CD de musique, ce sont quelques centimes !

Ce coût correspond au prix que vous pourriez payer un CD de musique datant de quelques années s'il n'y avait ni intermédiaire, ni marge. Même avec une marge de 200 ou 300%, le CD ne devrait pas coûter plus d'un EUR...

Et la rémunération des auteurs ?

On peut la concevoir de différentes manières :

  • * soit l'auteur rend un service (par exemple, un artiste fait un concert, ou il enregistre un disque), et on le rémunère uniquement pour le temps qu'il a passé à travailler. Ce schéma est celui que vivent la plupart des artistes (on l'oublie souvent) - les programmeurs de logiciels sont soumis au même régime (généralement, ils sont salariés).
  • * soit l'auteur perçoit des droits sur chaque utilisation ou diffusion de son oeuvre : c'est le schéma de la propriété intellectuelle classique, mis en oeuvre, par exemple, par la SACEM en ce qui concerne la musique.

Si le second schéma n'est pas inacceptable en soi, il a induit au moins deux dérives :

  • * Souvent, la propriété intellectuelle est déléguée au distributeur (en partie ou en totalité) : dans ce cas, ce n'est pas l'auteur, mais le distributeur, qui est rénuméré au titre d'une création... qu'il n'a pas créée !
  • * Dans la plupart des états occidentaux, la durée de protection des oeuvres, à l'origine de quelques années, a été étendue au-delà de toute mesure (jusqu'à 70 ans après la mort de l'auteur !). Ce dispositif était au départ conçu pour favoriser la créativité : comme l'a fait remarquer le juriste Lawrence Lessig, "à quoi bon favoriser la créativité d'un mort ?"

En France, il conviendrait d'ajouter la "redevance pour copie privée", que vous acquittez à chaque fois que vous achetez un support numérique (CD, DVD, disque dur...) et qui est supposée rémunérer les auteurs. Or la copie privée est un droit : comment expliquer que l'on rémunère les auteurs en contrepartie d'un droit dont on dispose (et dont l'exercice ne saurait donc constituer un préjudice) ? La seule explication, c'est de considérer cette redevance comme une compensation du piratage... autrement dit, comme une forme de droit à pirater (j'ai déjà payé, donc je me sers, disent les pirates... ont-ils foncièrement tort ?)

Ici donc, comme toujours, le bon équilibre est dans la mesure : un usage raisonné des deux modèles de rémunération (service et droit d'auteur limité dans le temps) conduirait à une rémunération équitable de tous les acteurs, tout en rendant le marché accessible.

Le piratage est un impôt progressif...

Cette phrase n'est pas de moi : elle est attribuée à Tim O'Reilly, célèbre éditeur américain.
Prenons exemple sur la musique : les artistes les plus diffusés pâtissent réellement du piratage. Mais c'est au profit de nombreux artistes inconnus, dont la musique n'est diffusée que grâce à l'échange de fichiers : la notoriété que cette diffusion leur confère leur permet de mieux remplir leurs salles de concerts, et de vivre dignement de leur art (les plus chanceux parvenant même au sommet du box office).
Donc, ce qui est perdu par quelques uns profite au plus grand nombre : en ce sens, le piratage est bien un "impôt progressif", acquitté par les plus riches au profit de tous - ce qui explique, entre autres, que nombre d'artistes s'opposent à tout "flicage" de l'internet.

Les risques du flicage

On a assez parlé des atteintes aux droits individuels, ainsi que du risque d'exclure des gens de l'internet (qui est bien plus qu'un espace d'échange de fichiers !), pour qu'il soit inutile de s'étendre davantage sur le sujet.
Mais il y a au moins deux autres dangers, souvent moins connus :

  • * Le premier est celui de la généralisation de technologies de chiffrage (ou "cryptage") : il existe déjà des réseaux "peer to peer" extrêmement sécurisés (comme "mute", par exemple). Sur ces réseaux, il est quasiment impossible de déterminer qui est qui, et qui fait quoi, sauf à mobiliser d'énormes moyens... sans même que le succès ne soit garanti !

On y trouve déjà aisément des contenus pédophiles, entre autres : le durcissement des mesures policières conduit au durcissement de la contre-mesure, lequel ouvre un boulevard aux véritables activités criminelles.

  • * Le second est le risque d'"erreur judiciaire" : supposons, par exemple, que mon voisin ait mal sécurisé son accès wifi (ou qu'il participe à un réseau de wifi communautaire). Si j'utilise sa connexion pour télécharger illégalement des oeuvres protégées, c'est lui qui verra son accès internet coupé... ce n'est pas très juste !


Pour conclure, un peu de politique politicienne...

Comme souvent dans le débat politico-économique, les conservateurs avancent masqués... et déguisés en libéraux !
Ce dont il est question lorsqu'on veut "fliquer" l'internet, ce n'est pas la protection des auteurs : c'est la protection des positions acquises.

Or un libéral, ce n'est pas quelqu'un qui défend les acquis : c'est quelqu'un qui défend le progrès par le biais de la compétition, de la création et du mérite.
A ce titre, qualifier de "libéraux" ceux qui nous gouvernent aujourd'hui serait leur faire un compliment qu'ils ne méritent pas : un conservateur est un conservateur, tout comme un chat est un chat...

mardi, avril 1 2008

Innovation zéro

Avez-vous quelque peu cherché à innover, à inventer quelque chose de nouveau, à créer ou même simplement à penser de manière originale ?
Si c'est le cas, vous vous êtes sans doute aperçu que c'est difficile et inconfortable (l'effort nécessaire pour créer est incommensurable à celui nécessaire pour copier, et se déroule le plus souvent sous des regards réprobateurs), alors même que nombre d'inventions paraissent a posteriori du domaine de l'évidence ("comment n'y ai-je pas pensé moi-même" ?).

Cette proposition ne serait-elle pas contradictoire si l'on n'était pas, foncièrement, des animaux stupides et conditionnés ?

Il existe dans l'histoire un exemple édifiant : l'invention du zéro.

Un enfant de 5 ans est capable de comprendre ce qu'est le zéro, devenu une évidence pour tout un chacun. Pourtant, il a fallu des siècles pour l'inventer, puis encore 1000 ans pour comprendre qu'il s'agissait d'un nombre (inventé comme une forme d'espace pour la notation positionnelle des nombres 300 ans avant JC, il fut défini comme résultat de la soustraction d'un nombre à lui-même en... 628) - sans compter le temps que le zéro a mis à se diffuser (introduit en Europe occidentale au XII ème siècle !).

Le zéro n'a pas seulement été retardé par notre stupidité : notre aveuglement (ou conditionnement) y est aussi pour quelque chose. Le zéro n'était réellement concevable que dès lors qu'une certaine conception des nombres se faisait jour (et réellement utile que combiné à la notation positionnelle - perçue comme seule efficace pour effectuer des calculs, mais longtemps freinée par le poids de la tradition et la pression de certains lobbies, dont le calcul était le fonds de commerce).

Il ressort donc que, d'une part, très peu d'individus auraient la capacité d'inventer le zéro - et qu'ils seraient encore moins nombreux capables de convaincre les autres de son utilité : car le frein le plus puissant à l'innovation, c'est notre conditionnement.

Il est a contrario notable qu'une fois le zéro inventé et diffusé, il est devenu partie intégrante de notre conception de la réalité - au risque de nous cacher, irrémédiablement, d'autres vérités, et de nous rendre incapables d'innovations qui auraient pu se faire jour dans un monde sans zéro : notre pensée est inconsciemment orientée par le zéro (comment penser comme si le zéro n'existait pas ?)

Nous n'avons donc qu'une vision étroite et bridée de la réalité : outre le fait que nous l'appréhendons avec des sens fort limités, notre formation nous inculque nombre d'idées préconçues dont nous ne pouvons ensuite nous dégager.
Prenons, à titre d'exemple, la géométrie Euclidienne : nous avons tous appris que la somme des angles d'un triangle est de 180 degrés. Faites l'expérience de tracer ce triangle sur une sphère au lieu d'un plan : la somme de ses angles sera alors de... 270 degrés.
Rien de nouveau : 180 degrés, c'est uniquement dans le plan Euclidien. Le problème, c'est que nous prenons ce postulat pour argent comptant - autrement dit, nous voilà persuadés de vivre dans un espace Euclidien, et nous allons baser nos raisonnements là-dessus. "Chance", nous vivons dans un espace (ou une portion d'espace ?) où la géométrie Euclidienne s'applique... presque. Ce qui renforce d'autant notre croyance qu'elle EST la réalité... cette "petite" approximation (qui perdure chez la plupart de nos contemporains - peu de quidams se méfient du triangle) nous a fait perdre quelques millénaires.

Tout est à l'avenant : l'industrie mécanisée et notre conception du temps découleraient de notre système d'écriture et de l'imprimerie (division des tâches, notion de subdivision, etc... que l'on applique ensuite à d'autres domaines), et notre science même découlerait de la religion monothéiste (avec un curieux effet de balancier : étant persuadé que Dieu ne s'incarne pas en toute chose, l'investigation est légitimée... alors même qu'une certaine conception de la morale et de l'autorité canalise le progrès).

Autrement dit, nous n'avons pas seulement une faible capacité d'invention : en plus, nous avançons avec des oeuillères, au sein d'un système qui nous dicte ce que l'on doit penser !
Et plus nous avançons, plus nous nous persuadons que nous détenons la vérité... que l'on essaie ensuite d'inculquer aux autres, au besoin par la force, déclarant ineptes d'autres formes de science ou de pensée qui nous sont inintelligibles, et se trouvent perdues à jamais (la médecine primitive, certaines conceptions du temps, et nombres de philosophies oubliées ont fait les frais de cette attitude... sans parler des nombreux savants, philosophes et inventeurs qui furent purement et simplement méprisés, traîtés comme fous, poussés au parjure, voire assassinés).

Nous sommes un peu comme un automobiliste qui ne voit que ce qui est éclairé par ses phares : l'étendue de notre connaissance se résume à cet étroit faisceau, et ce que nous ne connaissons pas est du même ordre que la nuit autour (la métaphore a quelque chose d'équilibré : les scientifiques se demandent encore où est passée... 90% de la masse de l'Univers !)

Quant à l'innovation, elle commence par une certaine attitude critique : la prochaine fois qu'on vous racontera que la somme des angles d'un triangle est égale à 180 degrés, demandez-vous si l'on ne vous prend pas pour un imbécile...

lundi, mai 7 2007

De la responsabilité du concepteur

Il n'est pas inimaginable que le concepteur d'un ustensile de cuisine ou d'un programme d'ordinateur cherche en fait, non pas à concevoir un ustensile ou un programme, mais à changer durablement l'ordre des choses. Son travail, même s'il vise un but mercantile, peut se révéler à terme un acte politique.

Sans pousser le raisonnement si loin, toute "bonne" conception doit s'inscrire dans un futur non encore prédictible : envisager les mutations qu'elle va provoquer, son réemploi comme un constituant de l'avenir sous la forme d'innovations ou d'usages futurs - et s'appliquer soit à rendre ce réemploi possible, soit à l'empêcher.

Enfin, il convient de ne pas oublier qu'il est dans la nature même d'une création d'échapper à son créateur, et qu'à ce titre mieux vaut être conscient de ses responsabilités.

Ces idées sont remarquablement résumées par la célèbre formule de Marshall McLuhan : "Le médium, c'est le message" ("Pour comprendre les média", 1964). Cet aphorisme éclaire d'un jour particulier la responsabilité et le pouvoir du concepteur.

McLuhan définit comme "médium" tout ce qui prolonge et étend les capacités de l'homme, et nous apprend que la nature du "medium" et la manière dont elle intéragit avec la nature humaine sont infiniment plus importantes que le contenu du "message" véhiculé.

Par exemple, le "message" porté par la mécanisation de l'industrie, c'est la profonde mutation sociale qu'elle a induite : le "contenu" produit par les usines mécanisées importe peu. Que l'on fabrique à la chaîne des voitures ou des saucisses n'y change rien : l'important, c'est l'impact des usines mécanisées sur l'ordre social.

Le vrai message est donc le medium lui-même, le contenu qu'il porte pouvant quasiment être négligé.

Ce principe est applicable aux média "classiques"; par exemple, le contrôle d'Internet par la voie du contenu (via le droit d'auteur, la censure, etc...), quoique prôné par nombre de législateurs et de moralistes, relève de l'aveuglement : prétendre contrôler un médium via son contenu est absurde.

Conséquence immédiate : tout concepteur porte une lourde responsabilité, toute innovation ayant une vie propre susceptible de modifier l'ordre social ou moral, ou encore de favoriser, ralentir, ou orienter le progrès et la connaissance.

A ce titre, l'exemple d'Internet est édifiant : ceux qui en ont jeté les bases travaillaient pour le compte de l'armée des Etats-Unis, peu réputée pour sa vision libertaire et sa transparence. Et il semble bien qu'ils aient conçu un medium délibérément incontrôlable, portant ainsi une vision du monde bien éloignée de celle de leur commanditaire, tout en respectant malgré tout les termes de leur contrat !

Plus récemment, Lawrence Lessig a montré que la technologie a un impact sur nos droits, impact qui échappe même au législateur, et qu'il résume par la formule "code is law" - "le code (ou le programme), c'est la loi" ("L'avenir des idées", 2005).

Les droits réels d'un citoyen dépendent de plus en plus des services que la technologie lui offre, du fait de l'omniprésence de celle-ci : à quoi sert une loi qui vous donne des droits si aucun moyen ne vous permet de les exercer ? A l'inverse, certains moyens techniques en libre accès peuvent vous donner des possibilités bien au-delà du droit, ou non encore adressées par celui-ci (et que l'usage pourra même transformer en droits de fait, inscrits plus tard dans la loi).

Le concepteur est donc dépositaire d'un pouvoir "législatif" : les moyens techniques qu'il met à disposition peuvent limiter ou étendre le champ d'application du droit, hors de tout contrôle démocratique ou étatique.

Celui qui conçoit un système doit a minima être conscient de ces effets dérivés. Hélas, c'est trop rarement le cas, et ces effets sont généralement perçus comme fortuits - quand ils ne prennent pas la forme de dommages collatéraux, parfois attribués à la fatalité.

A contrario, il est envisageable de les utiliser sciemment, en recherchant un effet produit qui dépasse de très loin la destination première de ce qui est conçu. Mais s'il très facile de tenir de tels objectifs secrets, et d'abuser au besoin un employeur ou un bailleur de fonds (ce qu'ont fait les concepteurs d'Internet vis-à-vis de l'armée américaine), il est beaucoup plus difficile de prédire les effets réels de l'innovation, ainsi que leur possible étendue temporelle, spatiale ou idéologique...

vendredi, mars 9 2007

Petit exercice de P2P (peer-to-peer) en java

Bon, un post un peu technique... Je ne puis résister au plaisir de vous livrer ce petit morceau de code (un petit programme java de 150 lignes en tout, composé de 2 fichiers : un client, et un serveur).

Il s'agit d'un exemple (assez basique) de système d'échange de fichiers en "peer-to-peer" (ou P2P).

Principes :
- Clients et serveurs disposent d'une liste d'adresses IP de serveurs connus (dans un fichier nommé "servers.list").
- Le client lance une requête spécifiant un nom de fichier à télécharger.
- Cette requête est transmise aux serveurs que le client connaît
- Lorsqu'un serveur reçoit une requête, il renvoie le fichier demandé s'il le détient, et sinon réémet la requête vers les autres serveurs qu'il connaît, etc... (la profondeur étant limitée à 3 serveurs, sinon les réémissions pourraient se poursuivre à l'infini).
- Dés que le fichier demandé est trouvé quelque part, il est ramené vers le client (via la chaîne d'appels) et la recherche s'arrête.
- Le serveur est multiprogrammé (exécution possible de plusieurs requêtes en parallèle, en utilisant des "threads").

Evidemment, je précise (pour être conforme à la loi DADVSI) que ce programme n'est absolument pas dédié à échanger des oeuvres protégées par le droit d'auteur (l'utiliser dans ce but serait donc un détournement manifeste de l'objectif dans lequel il a été conçu, à savoir comme exemple de programmation à visée pédagogique - pour que tout le monde puisse découvrir les bases de ce type de programmation).

De fait, il serait sans doute un peu trop limité pour un tel usage (ou bien inefficace, en regard de ce qui existe sur le web !), et comporte probablement quelques bugs (j'avoue l'avoir peu testé, juste le minimum), en plus de ne fournir aucune sécurité (qui n'était pas le but de l'exemple).

Quoiqu'il en soit, si quelque héraut de la DADVSI devait s'offusquer, qu'il sache que mes avocats l'attendent, et que j'ai l'heur de pouvoir les payer... De plus, je ne fournis ici que du texte, et pas un programme exécutable (il est donc probable que les lois sur la presse s'appliquent - à savoir droit de réponse ou de recours juridique sous 3 mois aprés publication), tout recours nécessitant de s'assurer auparavant que ce programme peut fonctionner (et d'avoir bien compris à quoi il sert).

Place au code, maintenant... bonne lecture !


//-------------//
// Server.java //
//-------------//


//-------------//
// Server.java //
//-------------//

package p2p;

import java.net.*;
import java.io.*;

public class Server implements Runnable {

  public static void main(String[] args) throws Exception {

    ServerSocket srv = new ServerSocket(1234);

    while(true) {
      Thread t = new Thread(new Server(srv.accept()));
      t.start();
    }
    // srv.close();
  }

  // Client socket in/out streams
  BufferedReader clientInput_;
  OutputStream clientOutput_;

  public Server(Socket client) throws Exception {
    clientInput_ = new BufferedReader(
      new InputStreamReader(client.getInputStream()));
    clientOutput_ = client.getOutputStream();
  }

  public void run() { // Executed upon Thread's start() method call
    try {
      int level = 3;

      // Read "level" information
      // (max depth if further server calls are necessary)
      String line = clientInput_.readLine();
      if(line != null) level = Integer.parseInt(line);

      // Read the name of the requested file
      if((line = clientInput_.readLine()) != null) {
        File f = new File("." + File.separator + line);
        System.out.print("Client request for file " + line + "...");
        if(f.exists()) {
          copyStream(new FileInputStream(f), clientOutput_, true);
          System.out.println(" transfer done.");
        }
        else if(level > 0) { // File is not here... maybe on another server ?
          System.out.println(" file is not here, lookup further...");
          // Lookup on other known servers (decrement depth)
          boolean found = lookupFurther(level-1, line, clientOutput_);
          System.out.println(found ? "Transfer done." : "File not found.");
        }
      }

      clientInput_.close();
      clientOutput_.close();

    } catch(Exception e) { } // ignore
  }

  /*
   * Lookup the requested file on every known server
   * Server list is in local "servers.list" text file (one IP address per line)
   */
  static boolean lookupFurther(int level, String fname, OutputStream out)
  throws IOException {

    BufferedReader hosts;
    try {
      hosts = new BufferedReader(new FileReader("servers.list"));
    } catch(FileNotFoundException e) {
      System.out.println("No servers.list file, can't lookup further !");
      return false;
    }

    String ip;
    boolean found = false;
    while(! found && (ip = hosts.readLine()) != null) {
      System.out.println("trying server " + ip);
      try {
        Socket s = new Socket(ip, 1234);
        PrintWriter srv = new PrintWriter(s.getOutputStream(), true);
        srv.println(level + "\n" + fname);
        int nbytes = copyStream(s.getInputStream(), out, true);
        s.close();
        found = (nbytes > 0);
      } catch(ConnectException e) { } // ignore
    }
    hosts.close();
    return found;
  }

  public static int copyStream(InputStream in, OutputStream out, boolean close)
  throws IOException {
    int nbytes = 0, total = 0;
    byte[] buf = new byte[1024];
    while ((nbytes = in.read(buf)) > 0) {
      out.write(buf, 0, nbytes);
      total += nbytes;
    }
    if(close) in.close();
    return total;
  }
}


//-------------//
// Client.java //
//-------------//

package p2p;

import java.net.*;
import java.io.*;

/*
* Usage: Client <filename>
* Lookup a file across one or more server(s), and bring it here.
* List of server IP addresses should be in local "server.in" text file
* (one IP per line)
*/
public class Client {

  public static void main(String[] args) throws Exception {

    String ip;
    boolean found = false;

    // Loop on servers list (obtained from local "servers.in" file)
    BufferedReader hosts = new BufferedReader(new FileReader("servers.list"));
    while(! found && (ip = hosts.readLine()) != null) {

      Socket s = new Socket(ip, 1234);
      PrintWriter srv = new PrintWriter(s.getOutputStream(), true);

      // Ask for requested file, max depth (calls to further servers) = 3
      srv.println(3 + "\n" + args[0]);

      // Bring back the file, if any
      File f = new File("." + File.separator + args[0]);
      FileOutputStream out = new FileOutputStream(f);
      found = (Server.copyStream(s.getInputStream(), out, true) > 0);
      out.close();
      if(! found) f.delete();

    }
    hosts.close();
  }


//-------------//
// Server.java //
//-------------//

package p2p;

import java.net.*;
import java.io.*;

public class Server implements Runnable {

  public static void main(String[] args) throws Exception {

    ServerSocket srv = new ServerSocket(1234);

    while(true) {
      Thread t = new Thread(new Server(srv.accept()));
      t.start();
    }
    // srv.close();
  }

  // Client socket in/out streams
  BufferedReader clientInput_;
  OutputStream clientOutput_;

  public Server(Socket client) throws Exception {
    clientInput_ = new BufferedReader(
      new InputStreamReader(client.getInputStream()));
    clientOutput_ = client.getOutputStream();
  }

  public void run() { // Executed upon Thread's start() method call
    try {
      int level = 3;

      // Read "level" information
      // (max depth if further server calls are necessary)
      String line = clientInput_.readLine();
      if(line != null) level = Integer.parseInt(line);

      // Read the name of the requested file
      if((line = clientInput_.readLine()) != null) {
        File f = new File("." + File.separator + line);
        System.out.print("Client request for file " + line + "...");
        if(f.exists()) {
          copyStream(new FileInputStream(f), clientOutput_, true);
          System.out.println(" transfer done.");
        }
        else if(level > 0) { // File is not here... maybe on another server ?
          System.out.println(" file is not here, lookup further...");
          // Lookup on other known servers (decrement depth)
          boolean found = lookupFurther(level-1, line, clientOutput_);
          System.out.println(found ? "Transfer done." : "File not found.");
        }
      }

      clientInput_.close();
      clientOutput_.close();

    } catch(Exception e) { } // ignore
  }

  /*
   * Lookup the requested file on every known server
   * Server list is in local "servers.list" text file (one IP address per line)
   */
  static boolean lookupFurther(int level, String fname, OutputStream out)
  throws IOException {

    BufferedReader hosts;
    try {
      hosts = new BufferedReader(new FileReader("servers.list"));
    } catch(FileNotFoundException e) {
      System.out.println("No servers.list file, can't lookup further !");
      return false;
    }

    String ip;
    boolean found = false;
    while(! found && (ip = hosts.readLine()) != null) {
      System.out.println("trying server " + ip);
      try {
        Socket s = new Socket(ip, 1234);
        PrintWriter srv = new PrintWriter(s.getOutputStream(), true);
        srv.println(level + "\n" + fname);
        int nbytes = copyStream(s.getInputStream(), out, true);
        s.close();
        found = (nbytes > 0);
      } catch(ConnectException e) { } // ignore
    }
    hosts.close();
    return found;
  }

  public static int copyStream(InputStream in, OutputStream out, boolean close)
  throws IOException {
    int nbytes = 0, total = 0;
    byte[] buf = new byte[1024];
    while ((nbytes = in.read(buf)) > 0) {
      out.write(buf, 0, nbytes);
      total += nbytes;
    }
    if(close) in.close();
    return total;
  }
}


//-------------//
// Client.java //
//-------------//

package p2p;

import java.net.*;
import java.io.*;

/*
* Usage: Client <filename>
* Lookup a file across one or more server(s), and bring it here.
* List of server IP addresses should be in local "server.in" text file
* (one IP per line)
*/
public class Client {

  public static void main(String[] args) throws Exception {

    String ip;
    boolean found = false;

    // Loop on servers list (obtained from local "servers.in" file)
    BufferedReader hosts = new BufferedReader(new FileReader("servers.list"));
    while(! found && (ip = hosts.readLine()) != null) {

      Socket s = new Socket(ip, 1234);
      PrintWriter srv = new PrintWriter(s.getOutputStream(), true);

      // Ask for requested file, max depth (calls to further servers) = 3
      srv.println(3 + "\n" + args[0]);

      // Bring back the file, if any
      File f = new File("." + File.separator + args[0]);
      FileOutputStream out = new FileOutputStream(f);
      found = (Server.copyStream(s.getInputStream(), out, true) > 0);
      out.close();
      if(! found) f.delete();

    }
    hosts.close();
  }

}
}
package p2p;

import java.net.*;
import java.io.*;

public class Server implements Runnable {

  public static void main(String[] args) throws Exception {

    ServerSocket srv = new ServerSocket(1234);

    while(true) {
      Thread t = new Thread(new Server(srv.accept()));
      t.start();
    }
    // srv.close();
  }

  // Client socket in/out streams
  BufferedReader clientInput_;
  OutputStream clientOutput_;

  public Server(Socket client) throws Exception {
    clientInput_ = new BufferedReader(
      new InputStreamReader(client.getInputStream()));
    clientOutput_ = client.getOutputStream();
  }

  public void run() { // Executed upon Thread's start() method call
    try {
      int level = 3;

      // Read "level" information
      // (max depth if further server calls are necessary)
      String line = clientInput_.readLine();
      if(line != null) level = Integer.parseInt(line);

      // Read the name of the requested file
      if((line = clientInput_.readLine()) != null) {
        File f = new File("." + File.separator + line);
        System.out.print("Client request for file " + line + "...");
        if(f.exists()) {
          copyStream(new FileInputStream(f), clientOutput_, true);
          System.out.println(" transfer done.");
        }
        else if(level > 0) { // File is not here... maybe on another server ?
          System.out.println(" file is not here, lookup further...");
          // Lookup on other known servers (decrement depth)
          boolean found = lookupFurther(level-1, line, clientOutput_);
          System.out.println(found ? "Transfer done." : "File not found.");
        }
      }

      clientInput_.close();
      clientOutput_.close();

    } catch(Exception e) { } // ignore
  }

  /*
   * Lookup the requested file on every known server
   * Server list is in local "servers.list" text file (one IP address per line)
   */
  static boolean lookupFurther(int level, String fname, OutputStream out)
  throws IOException {

    BufferedReader hosts;
    try {
      hosts = new BufferedReader(new FileReader("servers.list"));
    } catch(FileNotFoundException e) {
      System.out.println("No servers.list file, can't lookup further !");
      return false;
    }

    String ip;
    boolean found = false;
    while(! found && (ip = hosts.readLine()) != null) {
      System.out.println("trying server " + ip);
      try {
        Socket s = new Socket(ip, 1234);
        PrintWriter srv = new PrintWriter(s.getOutputStream(), true);
        srv.println(level + "\n" + fname);
        int nbytes = copyStream(s.getInputStream(), out, true);
        s.close();
        found = (nbytes > 0);
      } catch(ConnectException e) { } // ignore
    }
    hosts.close();
    return found;
  }

  public static int copyStream(InputStream in, OutputStream out, boolean close)
  throws IOException {
    int nbytes = 0, total = 0;
    byte[] buf = new byte[1024];
    while ((nbytes = in.read(buf)) > 0) {
      out.write(buf, 0, nbytes);
      total += nbytes;
    }
    if(close) in.close();
    return total;
  }
}


//-------------//
// Client.java //
//-------------//

package p2p;

import java.net.*;
import java.io.*;

/*
* Usage: Client <filename>
* Lookup a file across one or more server(s), and bring it here.
* List of server IP addresses should be in local "server.in" text file
* (one IP per line)
*/
public class Client {

  public static void main(String[] args) throws Exception {

    String ip;
    boolean found = false;

    // Loop on servers list (obtained from local "servers.in" file)
    BufferedReader hosts = new BufferedReader(new FileReader("servers.list"));
    while(! found && (ip = hosts.readLine()) != null) {

      Socket s = new Socket(ip, 1234);
      PrintWriter srv = new PrintWriter(s.getOutputStream(), true);

      // Ask for requested file, max depth (calls to further servers) = 3
      srv.println(3 + "\n" + args[0]);

      // Bring back the file, if any
      File f = new File("." + File.separator + args[0]);
      FileOutputStream out = new FileOutputStream(f);
      found = (Server.copyStream(s.getInputStream(), out, true) > 0);
      out.close();
      if(! found) f.delete();

    }
    hosts.close();
  }

}

mardi, novembre 21 2006

Bull offre à JOnAS un enterrement de 1ère classe ?

Du moins, c'est ce que laisse craindre l'annonce faire à JBoss World, Berlin : voir http://www.wcm.bull.com/internet/pr... , ou http://www.jboss.com/events/jbw_ber... .

A relativiser tout de même : le retentissement d'une telle annonce devrait être proche de celui de l'adoption d'un amendement à la constitution du Béloutchistan. Mais tout de même, l'annonce mérite le détour.

Pour ceux qui n'ont pas suivi le début du film, JOnAS est un serveur d'application JavaEE open-source (et certifié par Sun), pour l'essentiel développé par Bull, et hébergé par le consortium ObjectWeb. JOnAS fut même le serveur d'application de RedHat (avant le rachat de JBoss), et se place en seconde position sur le marché des serveurs d'application open-source, très loin derrière JBoss, mais avec une excellente image technique et quelques très grands déploiements dans le monde. Voilà pour le résumé de la saison 1 ...

Passons maintenant à l'annonce proprement dite, et décortiquons-en quelques aspects croustillants :

1) Bull annonce, grosso modo, qu'il va proposer du service sur JBoss. Tout le monde sait bien que c'est déjà le cas, la division Bull Services étant parfaitement agnostique en ce qui concerne les serveurs d'application (En dehors de JOnAS, Bull avait par exemple, dans un passé proche, conclu un partenariat avec BEA - et dispose également de belles références JBoss).
Il s'agit donc d'un non-message, ce qui n'est pas bien grave en soi (cf. la remarque ci-dessus sur la constitution du Béloutchistan - tout le monde s'en fiche, donc pas de dégâts).

2) L'annonce de Bull laisse planer le doute sur la continuation de JOnAS, concurrent direct de JBoss - de fait, il n'en est pas question dans l'annonce, et Bull réaffirme même son implication dans le consortium ObjectWeb, sans plus de détails.
Là, on est dans le domaine du contre-message : seuls les clients de Bull utilisateurs de JOnAS devraient le percevoir (le monde extérieur y étant imperméable), et le ressentir comme un signal négatif.
Donc, Bull adresse un message à ses clients qui provoque leur défiance, sans effet sur d'éventuels nouveaux clients... Etrange fait de marketing !

3) Ce qui est plus amusant, c'est que Bull annonce une coopération R&D avec JBoss : indépendamment du fait que l'on peut se demander qui va l'assurer (la démotivation interne des développeurs de JOnAS étant quasiment acquise dans une telle situation), cette coopération implique la fourniture par Bull à RedHat d'un module BPEL. Espérons qu'il y a une vraie contrepartie, faute de quoi Bull braderait quelque peu les bijoux de famille, et RedHat se trouverait comme par magie remis à niveau sur l'un de ses points faibles, le Business Process, sans bourse délier (attitude somme toute habituelle dans le business model de RedHat, depuis l'intégration de Linux !).

4) Autre point d'achoppement : le consortium ObjectWeb, en pleine crise de croissance, pourrait voir son avenir plombé par la chute de JOnAS; de toute évidence, cette éventualité ne joue pas non plus en faveur de Bull, ObjectWeb étant un fer de lance de son image de marque dans l'open-source !

5) Enfin, je ne peux que vous enjoindre à lire le communiqué de M. Barbéris, de chez Bull, à la fin de l'annonce : certes, M. Houellebecq a fait mieux en termes de novlangue informatique, dans l'introduction d' "extension du domaine de la lutte", mais avec un court avantage... Quant à M. Fleury, de chez RedHat, son allocution masque avec peine l'éclat de rire moqueur qu'il adresse au lecteur, du haut de son tas de dollars : Echec et Mat...

Pour résumer, donc, Bull fait un gros cadeau à RedHat tout en dissuadant ses clients et en démotivant ses équipes, et met en péril la stabilité d'ObjectWeb,le tout en un seul mouvement. Espérons au moins que les instigateurs de cette brillante tactique sont payés cher... ou qu'ils le sont par RedHat !

mercredi, mai 3 2006

L'éternité dans votre poche

Vous n'avez pas remarqué ?
En 1987, votre disque dur faisait 20 Mo. En 1994, 2 Go. En 2000, 20 Go et en 2006, 200 Go.
En gros, sa capacité se multiplie par 10 tout les 6 ans (par 2 tous les 18 mois, en fait : la fameuse "loi de Moore", applicable aux ordinateurs depuis qu'ils existent, s'applique également au stockage).

Bon, et alors, me direz-vous ?
Alors, dans 1 To (1 "téra-octet" ou 1000 "giga-octets", ce qu'il y aura dans votre PC familial en 2010), vous pouvez stocker 4 mois de vidéo haute définition (format DivX par exemple), ou encore 3 ans de musique non stop (format MP3 par exemple).

Bon, et alors, me direz-vous ?
Eh bien, c'est 256 fois plus tous les 12 ans.
En 2022, çà nous fait 85 ans de vidéo HD (votre vie entière filmée de la naissance à la mort).
En 2034, 21000 ans de vidéo HD, et près de 200.000 ans de musique.
En 2046, 5 millions d'années de vidéo HD (votre vie et celle de vos ancêtres jusqu'au singe, filmées en continu).

Dans une vingtaine d'années, l'intégralité de la musique enregistrée par l'homme depuis qu'il sait enregistrer devrait rentrer dans un baladeur.
A ce moment là, vous aurez l'éternité dans votre poche.
Avec tout ce que çà implique en termes de mutations sociales, d'usages, et de dérives... Je ne vais pas épiloguer là-dessus, les futurologues ont du boulot !

Et comme demain, 4 Mai 2006, nos chers Sénateurs examineront le texte de loi DADVSI (vous savez, les droits d'auteur dans la société de l'information), j'espère qu'ils mesureront à quoi ils seront confrontés quand chaque collégien portera dans sa poche toute la musique produite par l'homme depuis la Création...

jeudi, avril 27 2006

Cofidis et Atos te surveillent ! (1euro.com)

Un nouveau service de paiement en ligne à crédit vient de naître : 1euro.com, opéré par Cofidis et ATOS.
A la base, le concept peut séduire : paiement en ligne avec ouverture simultanée du dossier de crédit (sous réserve d'accord instantané), jusqu'où ira-t-on dans la simultanéité du crédit ?
Mais qui dit accord rapide dit aussi méthodes "rapides" pour s'informer de la solvabilité du client...

Il est ici question de commerçants en ligne fournissant à Cofidis des informations sur les bons et les mauvais payeurs, de manière automatique et sans contrôle d'aucune sorte (puisque la transmission est instantanée).

En l'occurrence, j'ai eu l'occasion de me pencher sur la documentation technique d'intégration de 1euro.com, et là, surprise... l'auteur incite le prestataire technique (et le commerçant) à communiquer au serveur de paiement des informations sur la solvabilité de ses clients, à travers des paramètres certes optionnels, dont la description suit (je cite littéralement la documentation technique d'intégration - regardez surtout les DEUX DERNIERS paramètres) :

[...]
V.la civilité (" M ", " Mme ", " Mlle ")
VI.le nom
VII.le prénom
VIII.adresse1
IX.adresse2
X.adresse3
XI.le code postal
XII.la ville
XIII.le pays
XIV.le téléphone fixe
XV.le téléphone portable
XVI.le flag indiquant si l'internaute est connu du commerçant (1 ou 0)
XVII.le flag indiquant si le commerçant a déjà eu des incidents de paiement avec cet internaute
[...]

Ces informations, "optionnelles" techniquement, le sont moins commercialement (le commerçant est largement incité à ne pas envoyer de mauvais payeurs à Cofidis s'il les connaît comme tels, faute de quoi sa responsabilité pourrait se voir engagée sous certaines conditions - la tentation est alors grande d'envoyer le maximum d'informations à Cofidis, pour se dédouaner).

J'ignore encore dans quelle mesure les internautes seront avertis de l'éventuel envoi d'informations concernant leur qualité de bon ou mauvais payeur (en plus d'informations personnelles objectives), par leurs commerçants à un organisme de crédit, et de manière automatique et instantanée...

En attendant, moi, je me permets de les avertir !

mardi, décembre 20 2005

Wikipedia et l'évolution

Les débats se font de plus en plus vifs autour de Wikipedia, encyclopédie collaborative alimentée librement par les internautes, et dotée d'un système de contrôle extrêmement laxiste (seules les publications grossièrement abusives sont rapidement censurées - racisme ou discrimination notoires, par exemple).
Quelques incidents ont été montés en épingle (un ancien collaborateur de Kennedy y aurait été accusé à tort d'être impliqué dans son assassinat !), et de nombreux intellectuels fustigent l'à-peu-près qui préside à la publication des articles (qui ne sont validés par aucune autorité légitime, autre que les internautes eux-mêmes).
Wikipedia ne serait donc pas une "encyclopédie", et le terme pourrait même tromper des internautes mal informés (une encyclopédie est censée ne publier que des connaissances validées, sans biais idéologique, en l'état du savoir humain de l'époque - or, Wikipedia ne saurait être lue sans esprit critique).
Toutefois, une étude parue dans "Nature" crédite Wikipedia d'un taux d'erreurs assez proche de celui relevé dans l'indiscutable "Encyclopaedia Britannica".
Alors, encyclopédie ou supercherie ?

Le débat ressemble fort à celui qui oppose les tenants d'une théorie de l'évolution finaliste (l'évolution ayant un but - que certains assimilent même à Dieu !) à ceux de l'approche évolutionniste (l'évolution résultant de l'action conjointe du hasard et de la nécessité, pour faire court).
Ou encore, aux deux écoles de l'Intelligence Artificielle : les cognitivistes (qui pensent que l'on peut modéliser l'intelligence, pour la programmer dans un ordinateur par exemple) et les connexionnistes (qui pensent que l'intelligence est une fonction adaptative, qui naît spontanément dans certains systèmes complexes - comme les réseaux de neurones).

Ce qui est sous-jacent, c'est la notion d'auto-organisation : l'organisation naît-elle d'une volonté consciente, ou peut-elle apparaître et croître spontanément ?

Dans le cas de Wikipedia, une encyclopédie engendrée par un processus d'auto-organisation peut-elle exister ?
Ou alors, le seul modèle viable est-il le modèle académique traditionnel, dirigé et finalisé ?
Enfin, l'un de ces modèles est-il supérieur à l'autre (si tant est qu'ils soient mutuellement exclusifs) ?

Quoiqu'il en soit, et quoiqu'il advienne, l'avenir sera passionnant : le fait même d'être partie prenante dans cette aventure pourrait changer notre relation au savoir, si ce n'est notre vision sociale et politique.

L'agitation, elle aussi, n'est pas près de se calmer : ne serait-ce que parce que des privilèges et des positions sociales, économiques, scientifiques établies sont en jeu.

Quant à faire des pronostics...

jeudi, avril 28 2005

L'INRIA est à vendre

Aujourd'hui, toute la presse française se congratule de la création d'un nouveau laboratoire commun Inria-Microsoft, célébré comme une avancée majeure en terme de collaboration recherche/industrie, ainsi qu'une preuve du dynamisme scientifique français.

Il est à craindre que cette initiative soit au contraire bien éloignée de ce dont la société civile a besoin, tant en termes d'indépendance technologique et de libre accès à l'information publique, qu'en terme d'échange et de transmission du savoir.

Certes, la position de l'Inria a toujours été contrastée dans ce domaine - voir par exemple sa politique de "valorisation", faisant la part belle aux brevets logiciels, et son retard à l'allumage patent vis-à-vis de l'open-source et de la mutation sociologique qu'il sous-tend. Rien de nouveau, donc, pour ceux qui connaissent l'institut

Certes, l'Inria est aussi traversée de courants multiples, et a aussi besoin de la caution morale apportée par des initiatives comme le W3C ou plus récemment ObjectWeb - parfois à son corps défendant, ou sans avoir pris toute la mesure des enjeux, mais on ne peut dénier à l'institut une certaine contribution au sens de l'histoire.

Pourtant, cette fois-ci, la ligne jaune semble avoir été franchie.

Sommes nous si affaiblis que nous ayons besoin, pour préserver la crédibilité (ou pire, la pérennité ?) d'un fleuron de notre Recherche Nationale, de l'associer à un éditeur Américain dont une bonne partie de nos institutions sont déjà peu ou prou dépendantes ?

Ou au contraire, nous croyons-nous si puissants que nous pourrions amener Microsoft à amender sa position, et agir d'abord pour l'intérêt général et la prospérité Européenne ?

Enfin, un citoyen peut-il être fier que l'argent des contribuables soit dépensé à promouvoir ce type d'initiative ? (dans Inria, il y a INR, soit "Institut National de Recherche" - et quand bien même ce serait "Institut Européen de Recherche", nous nous tromperions encore d'objectif).

Aujourd'hui, nous voilà si démunis que nous déposons l'Inria en gage, comme l'ultime bijou d'une noble famille désargentée... Aujourd'hui, c'est clair, l'Inria est à vendre.

jeudi, mars 31 2005

Go Mozilla !

Appelé à la rescousse informatique par mon père, utilisateur occasionnel d'un PC sous Windows comme la plupart des gens (et donc croulant sous les bugs et autres virus incompréhensibles même pour les initiés), je me suis permis d'installer subrepticement un navigateur Firefox, ainsi qu'un client de messagerie Thunderbird (à télécharger chez Mozilla), avant de glisser perfidement une petite phrase du genre "essaie ce truc-là à la place de ton Internet Explorer - respectivement, de ton Outlook - et tu verras bien si ça marche mieux".
Eh bien, ça marche mieux, on dirait (bon, jusque là, je m'y attendais).

J'ai noté au passage l'étonnement de mon paternel, quant à l'existence d'autres logiciels que ceux fournis par Microsoft et cités plus haut, ainsi qu'à la réalité d'un modèle open-source de toute évidence capable de produire des logiciels de cette qualité.
Pourtant, les faits sont là, et bien là.
Et peu à peu, la part de marché des logiciels Mozilla augmente, au détriment du tandem Outlook/Internet Explorer.

Mais le plus important, c'est la méthode : le bouche à oreille, et le "coup de main" du copain, voisin, fils, cousin, etc... informaticien, qui en profite pour installer les dits logiciels, comme si de rien n'était.
Ce que Tristan Nitot, responsable de Mozilla Europe aperçu au hasard d'une conférence, qualifie joliment de "Et Paf ! La clé USB" (vous venez donner un coup de main à un utilisateur, et d'un coup sans crier gare, vous dégainez votre clé USB avec Firefox dessus et "paf", vous l'installez). Il a raison, le garçon, ça marche !
"Go Mozilla", disais-je, et dépêchez-vous !

mercredi, mars 9 2005

IBM et l'Open-Source

Ne vous êtes-vous jamais demandé pourquoi IBM investissait des milliards dans l'Open-Source ?
Posez-leur la question, et vous obtiendrez des réponses classiques qui - quoique sensées (logiciel d'infrastructure performant pour leur offre "on demand", ouvertures en termes de service, image de marque, vision, rôle social, etc...) - n'éclaireront en rien votre lanterne, et surtout ne caractériseront aucune stratégie tangible.
Je ne vois donc qu'une explication : supposons qu'IBM parvienne à écraser ses concurrents (ce qui pourrait bien arriver). Ce jour-là, l'Open-Source sera l'alternative qui leur évitera de tomber sous le coup de lois anti-trust. L'utilisateur a le choix, donc il n'existe pas de monopole - IBM ne pouvant être soupçonné de contrôler l'Open-Source, aussi grande que puisse être son implication.
De plus, l'Open-Source pourrait bien aider IBM à écraser ses concurrents, justement. Microsoft, HP et Sun sont-ils solubles dans l'Open-Source ? Certainement bien davantage qu'IBM...
Des concurrents qui se dissolvent eux-mêmes dans un environnement qui devient à mesure protecteur pour vous, que pourriez-vous rêver de mieux ?
Quoiqu'il en soit, réjouissons nous : puisqu'IBM investit dans l'Open-Source, faisons bon usage de l'argent !

samedi, février 12 2005

Qu'est-ce qu'un standard ouvert ?

Ces temps-ci, on entend souvent parler à tort et à travers d'interopérabilité basée sur des standards ouverts.

Décryptage :

  • Un standard est ouvert s'il est public, et que quiconque a le droit de l'implémenter, de s'interfacer avec, d'en proposer des évolutions, et de se prévaloir d'une compatibilité au standard jusqu'à preuve du contraire (Exercice : ces propriétés s'appliquent-elles à J2EE ou aux formats XML d'Office ?). J'y ajouterai encore une propriété : un standard n'est ouvert que s'il est humainement possible de l'implémenter dans un temps fini (Exercice : cette propriété s'applique-t-elle à WS-I, aux 7 couches de l'ISO ou à X.500 ?).
  • Un standard est un standard s'il existe un consensus quasi-général à son sujet (par exemple, votre téléphone est connectable au réseau, et la pédale de frein de votre voiture est au milieu) : qui dit consensus quasi-général dit large disponibilité de systèmes compatibles sur le marché, ce qui garantit l'absence d'effet rareté (donc des coûts abordables) et une pérennité maximale (Exercice : ceci s'applique-t-il à .NET ou à l'AS/400 ?).
La seule chose qui soit vraie dans le discours domimant des grands éditeurs et intégrateurs, c'est que l'existence de standards ouverts est une condition d'existence de l'interopérabilité. Pour le reste, à vous de décrypter...

A noter que l'interopérabilité, présentée comme le Saint Graal en matière de systèmes d'information, n'est peut-être pas aussi importante que vous ne le pensez : on la confond trop souvent avec sa petite soeur, l'intégration, concept pourtant bien distinct et qui mériterait davantage de considération.

Alors, interopérabilité ou intégration ? Ceci sera sans doute l'objet d'un autre article...

- page 1 de 2