Sélectionnez le type d'affichage

Linux (fr)

  • [HS] Fête de la zique 2013 (Journaux LinuxFR)

    Cher journal,

    Comme chaque année, je fais un journal sur la fête de la musique pour inviter les gens à faire la fête (ou à faire de la musique).
    Comme chaque année, on va jouer là avec les "Thor se poile" devant Notre Dame de Paris.
    Comme chaque année, on va essayer de passer chez Claire Chazal.
    Comme chaque année, on va me demander le rapport avec le libre. Notre mascotte est un pingouin avec un chapeau rouge, ça compte pas ? De toute façon, ce journal est HS.
    Comme chaque année, on va nous demander des reprises. On en fait pas, c'est trop dur, même "si j'avais un marteau".
    Comme chaque année, on va me demander sous quelle licence on publie nos morceaux. On les dépose à la SDRM, ensuite c'est open bar et ce journal est en "CC by-sa".
    Comme chaque année, il va faire un temps incertain, voire même un temps de merde, alors prenez vos cirés.
    Comme chaque année, c'est un peu mon "moi, président".

    Lire les commentaires

  • Gestion de LDAP sous Debian : OpenLDAP (Journaux LinuxFR)

    Sommaire

    Il y a quelques mois, j'avais, sur un wiki, rédigé un tutoriel sur les bases LDAP. Souvent laissées de côté au profit de SGBDR (système de gestion de base de données relationnelles), considérés comme plus classiques (MySQL, PostgreSQL, …), les bases LDAP peuvent parfois s'avérer pratiques.

    Je me propose donc de faire une présentation de ce type de bases de données ici. Je ne cherche pas à inciter les gens à s'en servir, j'utilise moi-même bien plus souvent PostgreSQL, mais lorsqu'on administre plusieurs machines sous Debian (par exemple), on peut parfois se rendre compte que LDAP peut être très utile.

    Volontairement, je vais tenter de ne pas être trop technique ici, je parlerai de technique dans un autre journal.

    LDAP, c'est quoi ?

    LDAP est un acronyme signifiant Lightweight Directory Access Protocol. Il s'agit d'un protocole d'accès et de gestion d'annuaires (distants ou non). Pragmatiquement, c'est un système de base de données sous forme d'arbre. Chaque entrée de la base est un nœud, possédant des attributs (qui définissent ses caractéristiques), éventuellement des nœuds enfants, et souvent, un nœud parent (seul le nœud racine n'a pas de parent). LDAP est hiérarchisé, cela signifie qu'un nœud ne peut pas avoir plus d'un parent (on ne peut y accéder depuis la racine que par un chemin).

    Contrairement à ce que l'on peut voir dans un SGBDR, un attribut dans un nœud peut avoir zéro, une, ou plusieurs valeurs (qui n'a pas essayé de trouver une solution propre pour qu'un compte utilisateur dans une base type SQL puisse avoir plusieurs adresses mail par exemple).

    La structure hiérarchisée de LDAP impose que chaque nœud ait un identifiant unique, appelé DN (Distinguished Name), qui correspond à un chemin d'accès. Cet identifiant est en fait la concaténation de l'identifiant du nœud parent avec un identifiant propre au nœud courant. Voici un exemple de (toute petite) base LDAP, où l'on représente juste les nœuds.

    Simple représentation LDAP

    Par exemple, ici, le nœud me concernant a pour DN uid=peb,ou=users,dc=localdomain. Il peut contenir des informations, mais elles ne seront pas visibles ici.

    Les informations que peuvent contenir un nœud dépend du type d'objet que celui-ci doit représenter. Par exemple, un nœud peut représenter un utilisateur système, un groupe posix, une entreprise, une catégorie (dans un forum, par exemple), une machine. En fonction de cela, on voudra qu'il contienne des informations adaptées (adresse IP, nom, prénom, mot de passe, adresse MAC, …).

    À ce titre, une base LDAP intègre dans sa configuration des schémas. La plupart sont classiques et livrés tels quels. Souvent, quand on utilise une base LDAP, on ajoutera à ces schémas un ou plusieurs schémas faits maison, qui définiront les objets dont on a besoin, en plus des types d'attributs et d'objets déjà existants.

    Là où j'utilise LDAP, on a un schéma pour représenter les adhérents de notre association, leurs machines, etc… Voici un exemple du contenu d'un nœud.

    dn: aid=3775,ou=data,dc=crans,dc=org
objectClass: adherent
objectClass: cransAccount
objectClass: posixAccount
objectClass: shadowAccount
aid: 3775
charteMA: TRUE
chbre: 404
cn: PEB
droits: RTech
droits: Bureau
gecos: PEB,,,
gidNumber: 100
homeDirectory: peb
loginShell: /bin/zsh
mail: peb@pimeys.fr
mailAlias: taiste@pimeys.fr
nom: B
prenom: PE
uid: peb
uidNumber: 2573
userPassword: {SSHA}xwEP3a1xdO003bBeKfykI4gMbeGiT3kV

    On a donc des couples attributs/valeurs, stockés dans un nœud, qui le caractérisent. Certains, tels dn et objectClass, se trouvent dans tout nœud. D'autres sont propres au type de nœud (défini par l'attribut objectClass).

    LDAP, pourquoi ?

    Outre le fait que certaines choses se représentent mieux sous forme d'arbre que dans une base de données relationnelle, il y a des raisons pratiques d'utiliser LDAP sous Debian : la compatibilité avec les autres logiciels.

    Imaginons, vous administrez une vingtaine de machines sous Debian, et vous êtes quatre ou cinq administrateurs, plutôt que de créer des utilisateurs locaux, vous pourriez par exemple installer un serveur LDAP sur une de ces machines, le configurer, créer des utilisateurs dedans, et installer le paquet nslcd sur les autres machines. Celles-ci iraient alors demander au serveur LDAP les informations de connexion pour les utilisateurs qu'elles ne connaissent pas, et feraient le nécessaire pour qu'ils puissent se connecter.

    Ainsi, plus besoin de créer vingt fois le même utilisateurs, plus besoin de changer son mot de passe partout, etc. Seul défaut : si le serveur LDAP est dans les choux, plus personne ne peut se connecter avec son compte LDAP sur les machines. Il faut soit prévoir des utilisateurs locaux, soit utiliser le compte root (lui doit toujours être local).

    PAM et LDAP s'interfacent bien, donc (PAM et PostgreSQL aussi, mais le module développé à cet effet avait tendance à crasher, sous squeeze…), mais ce n'est pas tout !

    LDAP et postfix s'interfacent également bien (donc votre MX peut aller lire dans une (ou plusieurs) bases LDAP si un utilisateur existe, et lui délivrer des messages), LDAP et dovecot (POP/IMAP), LDAP et django s'interfacent bien, LDAP et Moinmoin s'interfacent bien, SOGo/Roundcube/Horde et LDAP s'interfacent bien, en fait, dans l'ensemble, la plupart des services qu'on peut souhaiter avoir et LDAP s'interfacent bien. Pourquoi s'en priver ?

    LDAP, c'est difficile ?

    L'approche de LDAP nécessite un peu plus de doigté que l'approche de PostgreSQL ou MySQL. Déjà, comme pour ceux-ci, il y a une syntaxe à apprendre : la syntaxe LDIF (pour LDAP Data Interchange Format), mais la configuration est plus technique, elle nécessite dans un premier temps d'écrire un fichier de configuration puis de l'incorporer avec une commande dans la base de configuration (la configuration des diverses bases LDAP sur un serveur est stockée dans… une base LDAP), après avoir choisi les schémas qui vous intéressent.

    Une fois la configuration faite, il faut créer une première base de données pour y stocker des données. Pour cela, il faut encore faire de la configuation, choisir le type de base de donnée (hdb, bdb, …). Il faut la peupler, sachant que par défaut, il n'existe pas une command-line spécifique comme psql ou mysql. On peut installer des outils (ldap-tools, shelldap, etc) pour faciliter la navigation. Essentiellement, la difficulté réside dans le fait que l'approche est différente des SGBD habituels, et dans la légèreté du protocole qui oblige à faire pas mal de choses à la main.

    Il faut savoir que la plupart des langages de programmation comportent une librairie pour communiquer avec les bases LDAP, cela diminue certaines difficultés que l'on pourrait croiser.

    LDAP n'est donc pas extrêmement difficile en soi, mais impose de s'adapter et de découvrir de nouvelles choses. Je proposerai prochainement une approche plus technique, entres autres comment installer et configurer un serveur LDAP. (paquet slapd sous debian)

    Un peu de doc

    [en] OpenLDAP, le site du projet OpenLDAP.
    [en] Zytrax, un très bon site avec pas mal d'infos.
    [en] Ubuntu propose également une doc.

    Ce dernier lien a d'ailleurs donné :
    [fr] Doc LDAP sur Ubuntu

    Bonne lecture !

    Lire les commentaires

  • Société de surveillance, fichage génétique et refus de prise d'empreinte (Journaux LinuxFR)

    Ceci n'est pas un journal traitant de Linux ou du logiciel libre, mais d'un sujet déjà évoqué de nombreuses fois dans ces colonnes : le fichage ADN par la police et la capacité à s'y opposer. Je me pose surtout des questions suite à un fait divers récent qui a réveillé le débat…

    Dans un cadre non-policier et dans le domaine biométrique un lecteur s'inquiétait du prélèvement d'empreinte digitale pour les cartes d'identité tandis qu'un autre alertait sur un projet d'identification biométrique dans les aéroport. Déjà certains soulevaient la question de la suspicion qui allaient s'installer envers ceux qui ne souhaitent pas être fiché.

    Dans le cadre policier et dans le domaine génétique, je me souviens d'un journal qui rappelait que la loi ne prévoyait pas de limite d'âge pour une inscription au fichier national des empreintes génétiques, à l'occasion d'un fait divers où deux enfants d'environ dix ans étaient menacés de prélèvement pour inscription au dit fichier pour un vol de tamagotchis et de balles rebondissantes dans un supermarché.

    Dans un autre journal, une autre personne rapportait la parole d'un ministre qui avait déclaré que les citoyens seraient mieux protégés si leurs données ADN étaient recueillies dès leur naissance. Le fichage généralisé est souvent cité comme exemple de « pente savonneuse » : le fichage ADN qui devait originellement être réservé aux meurtriers et délinquants sexuels, s'est petit à petit étendu jusqu'aux troubles à l'ordre publique.

    Le sujet est à nouveau revenu sur le devant de la scène dans de nombreux journaux et dépêches à propos du fichier EDVIGE. Dans les commentaire d'un journal à propos d'ACTA, une personne rappelait que la condamnation n'était pas nécessaire pour être fichée, qu'il suffisait d'être soupçonné.

    Mais surtout je me souviens d'un journal où quelqu'un racontait le jour où il avait été convoqué à la gendarmerie et aussitôt fiché génétiquement. Je cite les deux premiers commentaires de ce journal :

    #1 : Bon par contre fallait refuser le fichage ADN

    #2 : En tout cas, j'aurais refuse le prelevement ADN

    Et c'est le sujet qui m'intéresse : le refus du prélèvement génétique.

    Dans le journal sur les enfants voleurs de balle rebondissante, on apprenait que le père risquait de la prison en s'opposant au prélèvement génétique. Mais je ne lis pas tous les faits divers et jusqu'à maintenant je n'avais pas encore entendu parler de condamnation pour refus de prélèvement.

    Aujourd'hui en lisant un fait divers j'apprends qu'une personne a été condamnée pour « refus de prélèvement ». Certes, il n'est pas condamné que pour cela (il le serait pour « rébellion », aussi), mais voilà déjà un précédent : on peut être condamné pour refus de prélèvement, c'est le sujet de ce journal.

    Cela m'inquiète parce que cela signifie qu'il est possible de condamner quelqu'un interpellé sur soupçon, sans vérifier les soupçons, uniquement sur un détail de procédure après interpellation. Ce qui signifie que par un détail de procédure, une interpellation abusive peut mener à une condamnation en comparution immédiate, et ce indépendamment des motifs invoqués pour l'interpellation.

    Il suffirait d'être interpelé et de contester cette interpellation en refusant le prélèvement d'empreinte pour être condamné. Je trouve cela inquiétant, la condamnation peut faire suite au soupçon sans nécessité d'établir une relation entre l'objet du soupçon et la condamnation.

    Qu'en pensez-vous ? Est-il vraiment impossible de s'opposer à un tel prélèvement ? Est-ce que vous avez déjà été confronté à ce problème ?

    J'avoue que je ne sais pas quel aspect de la loi définit que le refus de prélèvement est un délit… Je comprends que cela ne simplifie pas les procédures et puisse prolonger une garde à vue par exemple, mais l'idée de pouvoir être interpellé et condamné indépendamment du motif de l'interpellation me chiffone un peu…

    Comme lu dans un journal à la manière de Niemöller :

    « Quand ils ont fiché la racaille,
    Je n'ai rien dit, je n'était pas une racaille.
    …
    Quand on m'a fiché,
    Et il ne restait plus personne pour protester.»

    C'est un peu mon inquiétude, surtout qu'on pourrait écrire la fin ainsi :

    « Quand est venue l'heure de me ficher, il ne restait plus personne pour protester, et j'ai de plus été condamné ».

    Lire les commentaires

  • Modification d'un paquet Debian (Journaux LinuxFR)

    Sommaire

    Il y a fort longtemps, j'ai modifié mon premier paquet Debian. Puis j'ai eu à le refaire. Puis encore une fois. Mais à chaque fois je notais rien de ma démarche. À chaque fois je recommençais presque de zéro. J'ai donc décidé de m'arrêter un instant pour documenter. Certes ça a été documenté et re-documenté des centaines de fois sur le Web, mais je le fais pour moi et si je le publie ici c'est pour m'assurer de ne pas perdre cette documentation (et parce que Facebook ne supporte pas les statuts avec la syntaxe Markdown). Et, finalement, si je le publie rien que pour moi ici, ça pourrait être utile à quelqu'un.

    Les outils de base

    Pour commencer nous allons installer les outils de base. On retrouve la liste sur le wiki Debian sauf que depuis la sortie de Wheezy, diff doit être remplacé par diffutils. Je rajoute aussi un outil : quilt, un outil de gestion de patch utilisé dans les paquets Debian. Cet outil, dixit Wikipedia, a été créé pour gérer les patchs du noyau Linux et est maintenant intégré à la gestion de paquet Debian.

    # aptitude install build-essential devscripts lintian diffutils patch patchutils quilt

    Une fois ces paquets installé je configure brièvement quilt pour un usage debianesque en ajoutant dans ~/.quiltrc les lignes suivantes (d'autres méthodes sont proposées sur le wiki) :

      QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_NO_DIFF_TIMESTAMPS=1
  QUILT_REFRESH_ARGS="-p ab"

    Les sources

    Le logiciel que je souhaite modifier porte le doux nom de dlm-pcmk et trouve sa source dans redhat-cluster. Afin d'obtenir tout ça, je me place dans mon répertoire de travail, par exemple ~/src/redhat-cluster. Tout étant prêt, je lance deux sortilèges :

      $ apt-get source redhat-cluster
  # aptitude build-dep redhat-cluster

    Le premier me retourne les sources prêtes pour être modifiées (décompressées et tout, si si), le deuxième m'obtient tout ce qui sera nécessaire pour les compiler. Les sources sont dans un répertoire nommé redhat-cluster-3.0.12 ; c'est là que tout va se dérouler ensuite (sous-entendre $ cd redhat-cluster-3.0.12).

    Nettoyage

    Afin de m'assurer d'avoir un environnement propre pour travailler, je demande aux petits lutins de le faire pour moi en utilisant leur langue et en me faisant passer pour la racine magique.

      $ fakeroot debian/rules clean

    Patcher

    À ce stade, il est temps de patcher les sources. Comme par hasard (si si), ce paquet source utilise quilt pour la gestion des patches (ce n'est pas forcément le cas mais ça tend à le devenir). Donc nous allons pousser tous les patches en stock sur les sources.

      $ quilt push -a

    Et nous allons créer notre nouveau patch.

      $ quilt new fix-dev-write-no-op

    Pour faire ce patch, je vais devoir modifier deux fichiers. Il faut donc les indiquer à priori (j'ai essayé de le faire à posteriori mais ça n'a pas fonctionner et je n'ai pas chercher à en savoir plus).

      $ quilt add dlm/include/linux/dlm_plock.h
  $ quilt add group/dlm_controld/plock.c

    Je fais mes corrections dans ces deux fichiers et je ferme le tout très simplement (à noter que les commandes quilt doivent être faites à la racine du paquet source).

      $ quilt refresh
  $ quilt pop

    Pour que mon changement ait de la gueule, je vais ajouter une entrée à la liste des changements Debian.

      $ dch -i

    Mon éditeur texte favori, Microsoft Word, s'ouvre et je décris mon changement.

    Compilation

      $ fakeroot debian/rules binary

    Et voilà, dans mon répertoire ~/src/redhat-cluster j'ai un ou plusieurs (dans mon cas plusieurs) .deb prêt a être installé sur mon système ou pousser dans mon dépôt Debian.

    Conclusion

    Le bug corrigé ici a été signalé à Debian, comme rien ne bougeait, j'ai adapté le patch de redhat, j'ai soumis à Debian (avant la sortie de Wheezy), mais le bug est toujours présent … donc je suis condamné à patcher ce paquet encore et encore.
    Par ailleurs, si vous devez juste importer un patch avec quilt, après le quilt push il suffit de faire quilt import $FILE.

    PS

    Si vous voulez nettoyer votre système à la fin (supprimer les build-dep), j'ai trouvé cette jolie ligne sur le web :

      $ sudo aptitude markauto $(apt-cache showsrc redhat-cluster | grep Build-Depends | perl -p -e 's/(?:[\[(].+?[\])]|Build-Depends:|,|\|)//g')

    Ça marche du tonnerre (il faut remplacer redhat-cluser par le nom de votre paquet, bien entendu).

    Lire les commentaires

  • MariaDB dénonce un jeu de licence par Oracle (Dépêches LinuxFR)

    Le rachat de Sun par Oracle avait entraîné l’absorption de MySQL AB par l'ogre de l'édition logiciel. Depuis, au moins deux forks de MySQL ont vu le jour : MariaDB et SkySQL, pour se réunir à nouveau au sein d'un unique projet newSQL. Un peu plus tard, Red Hat, a décidé de remplacer MySQL par MariaDb pour la prochaine version majeure de sa distribution phare : RHEL 7.

    MariaDB vs. MySQL

    C'est dans ce contexte que MariaDB a dénoncé les équipes de MySQL AB pour avoir silencieusement modifié la licence des pages de manuel de MySQL. La nouvelle licence est bien plus restrictive, puisqu'elle n'autorise plus la duplication de la documentation sous forme imprimée à des fins de redistribution, à moins d'obtenir l'accord d'Oracle.

    On attend avec impatience la réponse de MySQL AB ou d'Oracle.

    Lire les commentaires

  • Ma vie et debian... (Journaux LinuxFR)

    Bonjour,

    Je suis un utilisateur de Debian convaincu depuis 1999. J'ai bien fait quelques essais d'autres distributions, mais je suis toujours revenu à Debian. Hors hier soir, j'avais un serveur à réinstaller : ayant vu la dépêche sur debian 7.1, je me suis dit, parfait, c'est parti !!

    Pour la première fois depuis longtemps, l'installation ne s'est pas du tout bien passé, et j'ai eu envie de partager mon désarroi… Je vous préviens, c'est long, c'est chiant, je ne vous oblige pas à lire, mais moi, ça me fait du bien de l'écrire !

    J'allume le serveur, je boote sur le CD netinst amd64 fraichement gravé : 1ère impression "install with speech synthesis". WHOAAAA, faudra que je teste un jour, mais pour le moment, j'en reste à la version install classique (ncurses). Comme c'est un serveur HP proliant, j'ai préparé une clé USB avec le firmware BNX2 dessus que je branche.

    C'est donc parti : langue, clavier, détection de matériel… Tiens, il me dit qu'il lui manque le firmware BNX2. Bizarre… Je débranche ma clé, je vais vérifier sur mon poste de travail, pas de problème, le fichier est bien là. Je rebranche ma clé sur un autre port USB du serveur (on sait jamais), je relance l'analyse puisque l'installateur me le propose. Chou blanc, toujours rien. Changement de console (ctrl + f4), plein de lignes comme quoi il arrive pas à monter la clé dans les logs. Crogneugneu : changement de console (ctrl + F2), activation de la console et "mount /dev/sda1 /mnt" --> invalid argument. Putain fais chier !! Pardon. Retour dans les logs, et je constate pleins de lignes ou FAT-fs n'arrive pas à monter. Ben oui, ma clé est en NTFS !!! J'ai juste essayé un "mount -t ntfs /dev/sda1 /mnt", qui à foiré lamentablement, et je suis retourné sur mon poste de travail re-formater ma clé en FAT32, et remettre le firmware dessus. Halleluja (dans sa version Jeff Buckley), ça marche, j'ai mon firmware !!!

    Donc point 1 : ne pas utiliser de périphérique NTFS pendant l'install…

    Je continue : configuration DHCP ok, configuration des disques : tiens, il me propose ma clé /dev/sda et mon disque RAID en /dev/sdb, pas grave, je configure le LVM sur sdb, et je continue.

    Jusqu'à la configuration du proxy : Eh oui, j'ai un proxy. Là, je gaffe, je mets "proxy:3128" en oubliant le "http://", ok, c'est ma faute, j'ai qu'à savoir lire. Forcément, échec de la récupération des archives. Pas grave, l'installateur me demande "changer de miroir", ce que je fais, il me redemande le proxy, et je remet comme il faut "http://proxy:3128". Sauf que ça ne marche toujours pas… Je recommence encore une fois, on sait jamais, je me suis peut être trompé à taper le nom, un clavier qui blo ça arrive. Mais non, toujours pas. J'essaye alors avec l'adresse IP du proxy, mais rien n'y fait. Hop, retour sur la fenêtre de logs : impossible de joindre 3128:80.. Pardon ??? Je retourne sur la première console, je vérifie la chaine de caractère, je revalide, je retourne voir les logs : impossible de joindre 3128:80 . Bordel de 100 000 nom d'un pipe !! J'annule, je recommence la configuration des dépots depuis le début, et là miracle !!! Ca marche !!!!

    D'ou le point 2 : si tu t'es planté sur le proxy au départ, insiste pas à changer le miroir, il ne prendra plus en compte le nouveau proxy que tu lui mettras !

    L'installation se déroule alors plutôt bien et j'arrive au bout. Il me demande s'il doit installer GRUB sur le secteur d'amorcage : ben oui, t'es tout seul sur le serveur, vas-y fais toi plaisir. Je valide et je vois, sous la barre d'avancement "grub-install sur /dev/sda"…. Non, il aurait quand même pas fait ça ????? Je redémarre, j'enlève le CD et la clé USB, et c'est le drame : pas de GRUB, il me l'a installé sur la clé USB, ce con !!!!! Je remets la clé, et ça démarre. Connexion root, je vérifie le nom des disques avec "mount", j'enlève la clé, et un petit coup de "grub-install /dev/sda" et "update-grub" pour le cas où, reboot, et ça roule…

    Point 3 : virer la clé avant l'install de grub… Encore que rien ne m'assure que ça aurait marché, j'ai pas essayé.

    La vache, c'est la première fois depuis bien longtemps que je dépasse le 1/4h à installer une debian de base.

    Merci à ceux qui m'ont lu, vous m'avez économisé une séance chez le psy.

    C'était quelques minutes dans la vie d'un admin.

    Tof

    Lire les commentaires

  • LLVM 3.3 et Clang 3.3 (Dépêches LinuxFR)

    Le projet LLVM est un ensemble de technologies modulaires et réutilisables destinées à construire des chaînes de compilation et des compilateurs. Ce projet a grandi depuis ses débuts en tant que projet de recherche à l'Université de l'Illinois pour maintenant rivaliser avec l'autre grand compilateur du monde libre. À l'aube de ses 10 ans, le projet est on ne peut plus actif, attirant aussi bien des industriels (ARM, IBM, Qualcomm, Google, Intel, etc.) que des chercheurs.

    logo LLVM

    Le projet LLVM, ainsi que Clang, le compilateur C/C++/ObjectiveC officiel du projet, sont sortis dans leur version 3.3 le 17 juin 2013. LLVM apporte la prise en charge de nouvelles architectures. Clang implémente désormais la totalité du standard C++11. Ces nouveautés sont détaillées dans la seconde partie de la dépêche.

    La conférence européenne LLVM 2013 qui s'est déroulée les 29 et 30 avril dernier à Paris a permis de voir certaines améliorations possibles qui seront peut-être un jour intégrées dans LLVM/Clang.

    Enfin, il est important de noter que LLVM a reçu le 2012 System Software Award rejoignant ainsi Eclipse (2011), Java (2002), TCP/IP (1991) et tant d'autres.

    Sommaire

    LLVM

    Architectures

    De nouvelles architectures sont désormais prises en charge par LLVM 3.3 : AArch64, z/Architecture et R600. D'autres architectures ont été améliorées : x86, ARM, MIPS et PowerPC.

    AArch64

    L'architecture AArch64 est la nouvelle architecture 64 bits des processeurs ARM. La particularité de cette architecture est qu'il n'existe à l'heure actuelle aucun matériel avec cette architecture. Mais sa prise en charge dans les compilateurs et dans les systèmes d'exploitation suit son cours.

    En ce qui concerne LLVM, il est déjà possible de compiler du C99 ou du C++03 sur Linux si le code et les données statiques ne dépassent pas 4 Gio. Il est aussi possible de générer des informations de débogage au format DWARF.

    z/Architecture

    La z/Architecture est l'architecture des mainframes d'IBM zSeries. Ulrich Weigand qui travaille pour IBM a fait état de l'avancement de la prise en charge de cette architecture en précisant que LLVM était maintenant considéré comme un composant critique pour IBM. Il cite notamment l'utilisation de LLVM en tant que compilateur JIT dans le pilote Mesa/Gallium llvmpipe et dans certaines applications de base de données propriétaires. Preuve que LLVM dépasse largement le petit monde de la compilation C/C++.

    R600

    On a plutôt l'habitude de lire des nouvelles de l'architecture R600 dans les nouvelles du noyau au chapitre des améliorations des cartes graphiques. Et bien LLVM n'est pas en reste puisque la prise en charge de cette architecture a été ajoutée à LLVM dans le cadre du développement des pilotes libres Mesa3D. LLVM est dans ce cas utilisé en conjonction avec Gallium3D pour la prise en charge d'OpenCL et optionnellement pour la compilation des shaders OpenGL.

    x86 et ARM

    La nouvelle interface TargetTransformInfo permet dorénavant aux outils travaillant au niveau de la représentation intermédiaire d'avoir des informations sur le coût des instructions de manière à pouvoir faire de meilleurs choix. Cette interface a permis de définir un modèle de coût pour les architectures x86 et ARM et donc de potentiellement améliorer le code obtenu. Cette fonctionnalité est utilisée pour la vectorisation des boucles qui est maintenant activée au niveau d'optimisation -O3.

    MIPS

    Clang prend désormais en charge des options concernant l'ABI (32 ou 64 bits, gros-boutisme ou petit-boutisme, simple précision ou double précision). De plus, l'ensemble d'instructions DSP-ASE (Application-Specific Extension) peut maintenant être généré directement sans avoir besoin d'une fonction intrinsèque (builtin). Ces instructions servent essentiellement pour les applications multimédia.

    PowerPC

    La prise en charge de PowerPC a été grandement améliorée sur de nombreux points : meilleure allocation de registres, lecture et écriture 64 bits atomiques, amélioration de la génération de code pour les comparaisons et les accès mémoire non-alignés, prise en charge de setjmp/longjmp en ligne ainsi que d'instructions de PowerISA 2.04, 2.05 et 2.06.

    LLVM peut maintenant lire de l'assembleur PowerPC.

    Divers

    La documentation de LLVM et de Clang est désormais générée à l'aide de Sphinx. Ce passage par Sphinx a permis de mettre de l'ordre dans toute la documentation et le résultat est bien plus lisible et compréhensible qu'auparavant.

    Clang

    Prise en charge complète de C++11

    Clang prend désormais en charge l'intégralité de C++11. Les derniers éléments apparus dans Clang 3.3 sont les suivants.

    Prise en charge des attributs

    Clang prend en charge la syntaxe générique pour les attributs ainsi que les deux attributs [[noreturn]] (qui permet de spécifier qu'une fonction ne reviendra jamais) et [[carries_dependency]] (qui permet de prévenir le compilateur de ne pas émettre de barrière mémoire inutile).

    Héritage de constructeur

    Clang gère maintenant l'héritage de constructeur qui permet d'utiliser un constructeur de la classe mère sans avoir à le réimplémenter dans la classe fille. La nouvelle GCC 4.8 donne plusieurs exemples pour comprendre le principe.

    Variables thread_local

    Clang permet de définir des variables locales aux fils d'exécution via le mot-clef thread_local. La principale difficulté est la construction et la destruction d'objets qui sont placés dans la mémoire locale de la tâche. Il est nécessaire d'avoir une gestion au moment de l'exécution (runtime) à travers l'appel à la bibliothèque __cxa_thread_atexit qui n'est pour l'instant disponible que dans celle fournie avec G++ 4.8.

    C++1y

    On vient à peine de s'habituer à C++11 que la prochaine version est déjà sur les rails. Pour l'instant, C++1y apporte principalement des améliorations et des corrections par rapport à toutes les nouveautés introduites dans C++11. Ce nouveau standard devrait apparaître en 2014.

    LLVM implémente déjà certaines de ces corrections qui peuvent être activées via l'option -std=c++1y.

    Divers

    Clang permet désormais d'utiliser des identifiants étendus pour C99 et C++, c'est-à-dire des identifiants qui utilisent certains caractères Unicode en plus des caractères ASCII traditionnels. Il est possible d'écrire ces identifiants en UTF-8 ou avec les notations \uXXXX ou \UXXXXXXXX.

    Analyseur statique

    L'analyseur statique de Clang a gagné quelques fonctionnalités.

    L'analyse inter-procédurale a été améliorée sur de nombreux points : les constructeurs et destructeurs sont mieux traités, les faux positifs concernant le déréférencement de pointeur nul ont été diminués et l'analyse est globalement plus rapide.

    Les nouvelles erreurs suivantes sont détectées :

    • utilisation d'un pointeur après sa désallocation dans le cas d'un delete du C++ ;
    • détection d'un allocateur et d'un désallocateur non-concordant (malloc/delete ou new/free).

    Un outil de migration vers C++11 : cpp11-migrate

    L'arrivée de C++11 permet d'adopter des syntaxes qui sont parfois plus concises et moins génératrices d'erreur. On pense notamment à la définition des itérateurs qui peut maintenant être évitée de deux façons, soit par le mot-clef auto qui permet d'inférer le type localement, soit via la nouvelle forme du for qui itère directement sur les éléments sans passer par un itérateur.

    Seulement, de grosses bases de code utilisent la vieille syntaxe et il est impensable de devoir tout changer à la main. C'est là qu'intervient l'outil cpp11-migrate. Cet outil basé sur les bibliothèques LibTooling et LibASTMatchers permet d'automatiser ces tâches et d'appliquer des transformations au code.

    À l'heure actuelle, les transformations suivantes sont prises en charge :

    • le for basé sur les intervalles. Que ce soit via des itérateurs, ou en parcourant un tableau ou même un container qui implémente l'opérateur d'indexation (operator[]), la transformation se fait automatiquement ;
    • l'introduction de nullptr partout où est utilisé NULL ou 0 (qui était conseillé par rapport à NULL en C++ jusque là) ;
    • le remplacement du type dans une déclaration par auto. Il se fait dans les cas suivants : quand le type est un itérateur d'un container de la STL ou quand l'initialiseur est un appel à new ;
    • l'ajout d'override. Quand une méthode virtuelle est ré-implémentée dans une classe fille, il est maintenant conseillé d'ajouter l'attribut override. L'outil peut s'en charger automatiquement.

    Les options de cet outil permettent de calibrer le degré de modification pour être sûr de ne pas détruire tout un projet.

    Cet outil a été appliqué en test sur des projets de taille assez conséquentes, LLVM et ITK, ce qui a permis de détecter de nombreux bogues, et d'améliorer son efficacité et sa robustesse. Il est prévu de l'appliquer sur LLDB, OpenCV et Poco.

    Logo LLVM 2

    LLVM et Clang dans Debian

    Dès qu'on parle de LLVM/Clang et Debian, il faut bien évidemment évoquer l'énorme travail de Sylvestre Ledru. En plus de son travail d'intégration de LLVM/Clang dans Debian, vous trouverez une entrevue de ce développeur très actif.

    Versions journalières ( nightly builds ) LLVM et Clang pour Debian

    Des versions journalières de LLVM et Clang pour Debian et Ubuntu sont désormais construites et accessibles sur un dépôt particulier, uniquement pour les architectures i386 et amd64.

    Entrevue de Sylvestre Ledru

    Bonjour Sylvestre, avant toute chose, est-ce que tu peux te présenter brièvement pour ceux qui ne te connaissent pas ?

    Bonjour, j'ai différentes casquettes au quotidien. Mon employeur est Scilab Enterprises. J'y fais aussi de la gestion de projets (pour des clients ou de Recherche et Développement). Je participe aussi au développement sur Scilab (logiciel libre de calcul numérique). Je travaille en parallèle pour IRILL en tant que community manager (grosso modo, je fais de la communication et je participe à l'organisation d'évènements). Par exemple, j'ai la chance d'y travailler avec Roberto Di Cosmo, Julia Lawall ou Stefano Zacchiroli. Enfin, je suis impliqué dans Debian et Ubuntu. Je maintiens plus d'une soixantaine de packages tout en étant trésorier de Debian France.

    Quand as-tu été amené à t'intéresser à LLVM et pourquoi ? Est-ce que tu utilises LLVM quotidiennement et dans quel cadre ?

    Initialement, je suis venu à LLVM plutôt via Clang. J'avais vu une news passer sur Linuxfr sur l'amélioration du support C et C++. Étant convaincu que compiler un logiciel avec différents compilateurs améliore la qualité du code et des applications, j'ai commencé à l'utiliser pour développer sur Scilab. Ensuite, j'ai commencé à m'y intéresser dans le cadre de Debian. Un peu à la manière dont on a réussi à proposer plusieurs noyaux (Linux, HURD et KFreeBSD), je cherche à rendre Debian agnostique en terme de compilateur. Enfin, synergie entre mes intérêts et les besoins de Scilab, dans le cadre du GTLL (Groupe Thématique Logiciel Libre) de Systematic, nous avons monté un projet intitulé Richelieu qui vise à apporter de la compilation à la volée (just-in-time) dans Scilab via LLVM/VMKit. Démarré en novembre dernier, j'en assure la coordination.

    Qu'est-ce que tu trouves intéressant dans LLVM/Clang d'un point de vue technique et d'un point de vue utilisateur, en particulier en comparaison du vénérable GCC ?

    D'un point de vue utilisateur, avant tout, la qualité des avertissements et erreurs. J'ai toujours un peu de mal avec les pages d'erreurs de g++ lorsque l'on traite avec les templates alors que Clang produit des messages plus clairs et plus concis. Cependant, pour être fairplay, poussé par la compétition, GCC, en particulier dans sa version 4.8, améliore aussi fortement ces points (comme par exemple le travail de Dodji Seketeli sur l'expansion des macros lors de l'affichage d'erreurs). D'ailleurs, Il ne faut pas voir gcc et clang comme des adversaires : il ne faut pas oublier qu'il avait été envisagé que LLVM soit la base d'une future version gcc.

    En parallèle, LLVM/Clang proposent de nombreuses pluging/extensions très
    intéressantes comme :

    • scan-build, un analyseur statique de code C/C++/Objective-C pour trouver des bugs « complexes »
    • {Address,Thread,Memory}Sanitizer qui proposent d'instrumenter du code binaire pour trouver des erreurs lors de l'exécution.
    • libclang pour travailler sur l'arbre de syntaxe abstrait (AST) C/C++ pour écrire des plugins ou extensions (compilation source à source par exemple).

    Enfin, d'un point de vue technique, c'est du code C++ bien architecturé, très bien commenté avec une grosse base de tests. Ainsi, LLVM/Clang permet à des académiques de proposer des implémentations de leurs travaux de recherche d'une manière plus simple et plus rapide qu'avec gcc.

    Ça peut paraître surprenant mais la communauté LLVM est très forte et amicale. Pas mal de développeurs expérimentés (comme Duncan Sands, Rafael Espindola, etc.) encouragent et aident les débutants à contribuer. Par exemple, lorsque j'ai contribué à quelques patches pour le support de HURD et KFreeBSD dans LLVM, j'ai été surpris de recevoir un mail d'encouragement d'un développeur employé d'Apple se félicitant de voir le logiciel porté sur ces plateformes.

    Tu as récemment co-organisé la conférence des développeurs LLVM Europe. Quel bilan technique et humain tires-tu de cette conférence ?

    Cette conférence a été organisé par les mêmes personnes (Duncan Sands, Tobias Grosser, Arnaud De Grandmaison et moi-même) qui proposent depuis presque deux ans les Meetup LLVM. L'organisation a été facilité par la participation active de ARM et par les sponsors. En soit, la conférence fut très intéressante. Parfois un peu trop technique pour des gens pas assez dans le projet (ou pas directement intéressés par un sujet) mais dans l'ensemble, elle démontre la vigueur de la communauté (on a dû refuser beaucoup de monde à la conférence). De plus, comme la plupart des projets FLOSS, beaucoup de participants ne se voient que lors de ce genre de conférence. C'est vraiment important pour renforcer la communauté, faire progresser les projets et en lancer des nouveaux.

    Les vidéos sont disponibles sur le site IRILL et Renato Golin, de Linaro, a publié un compte rendu sur le blog LLVM.

    Tu es également développeur Debian et tu packages LLVM et Clang pour Debian. Peux-tu nous parler du travail que tu mènes pour pouvoir rendre Debian indépendante du compilateur ?

    Mon objectif final est simple : avoir une version de Debian compilé avec Clang.

    Le cheminement pour atteindre cet objectif est plus complexe. Évidement, dans un premier temps, le premier travail est d'avoir un package Clang qui fonctionne bien. Tâche pas toujours facile car Clang se base sur les headers de gcc/g++ et le runtime C++ de g++ et qu'ils ont récemment pas mal changé avec le multiarch dans Debian.

    Ensuite, avec l'aide de Lucas Nussbaum, j'ai tiré parti du cloud Amazon AWS pour effectuer des reconstructions massives de l'archive Debian avec Clang. La version 3.2 a permis de valider la qualité du compilateur en terme de support du C et C++. Maintenant, l'essentiel des erreurs de compilation se trouvent dans des erreurs de programmation dans les packages upstreams. Quelques exemples :

    Cependant, il est important de préciser que ni les performances du binaire, ni la qualité de celui-ci sont testés. Pour cela, depuis quelques semaines, nous avons une infrastructure autonome de construction de packages basée sur Clang au lieu de GCC. Ce travail a été réalisé dans le cadre du Google Summer of Code 2012 par Alexander Pashaliyski, mentoré par l'hyperactif Paul Tagliamonte et moi-même. La méthode est assez bête : vu que clang accepte les mêmes arguments que gcc, on remplace le binaire gcc par clang et on lance la compilation du package de la même manière que d'habitude. Cette plateforme permet aux packageurs Debian et Ubuntu de vérifier que leurs packages compilent correctement avec Clang, et les corriger si besoin. J'espère qu'elle sera aussi utile aux développeurs de logiciel intégré dans Debian pour les encourager à corriger les problèmes soulevés par ce nouveau compilateur (et ainsi leur prouver que Clang est mature).

    En parallèle, nous avons publié un dépôt Debian avec bon nombre de packages compilés avec Clang :

    deb http://clang.debian.net/repository-2013-04-07/ unstable-clang main

    Ce dépôt devrait permettre de tester la qualité des binaires produits.

    Enfin, j'ai mis en place une instance Jenkins pour construire automatiquement des nightly builds de la toolchain LLVM pour Debian et Ubuntu. Ces dépôts sont publiés sur le site officiel de LLVM.

    À plus long terme, j'aimerais pousser l'usage de /usr/bin/cc et /usr/bin/c++ au lieu de gcc et g++. Dans de nombreux packages, l'usage de gcc est hardcodé. Malheureusement, même si les retours de la communauté Debian sont dans l'ensemble positif sur cette initiative, je pense que cet objectif prendra quelques années.

    Enfin, malgré tout, il restera un gros travail pour le support de certaines architectures supportées par Debian mais pas par LLVM.

    Que penses-tu de l'évolution très rapide de LLVM/Clang ? Quels sont les principaux défis pour LLVM/Clang que tu vois pour le futur ?

    Je trouve l'évolution de LLVM et Clang assez extraordinaire. Il y a un engouement fort à la fois autour de ce « nouveau » compilateur mais aussi autour de la plateforme qu'est LLVM en tant que tel. Les contributions se font simplement : liste des diffusions très (trop ?) actives et les permissions au SVN facilement données.

    Un des exemples de réussite de la toolchain LLVM est emscripten. Projet de la fondation Mozilla, il permet de compiler des codes C/C++ en Javascript. Il utilise LLVM et Clang pour générer une représentation intermédiaire (IR) qui sera lue en Javascript.

    Il y a de nombreux projets autour LLVM qui sont prometteurs comme libc++ (une nouvelle implémentation du runtime C++), lldb (un débugger tirant parti de libclang pour l'analyse de C++) ou encore lld (linker).

    Quant aux défis, ça n'est un secret pour personne mais LLVM/Clang sont fortement poussés par des grosses boîtes comme Apple, Google, Intel ou Samsung. Pour leurs produits ou leur utilisation interne, ils utilisent bien souvent des révisions du dépôt Subversion. Or, en particulier d'un point de vue distributions, je pense que l'on aura besoin d'aller vers des révisions mineures de la toolchain LLVM. En effet, pour le moment, seules des versions majeures (3.1, 3.2 et maintenant 3.3) sont publiés. Les patches devant être backportés à la main par les packageurs (par exemple, le package llvm-3.2 de la dernière Ubuntu contient un backport du support r600).

    J'espère aussi que les contributions resteront fortes. Sans partir dans un débat GPL vs BSD, certains acteurs pourraient être tentés de garder pour eux des évolutions fortes et d'autres de forker le logiciel à la manière de Webkit/Blink.

    Techniquement, j'aimerais voir LLVM/Clang améliorer les performances des binaires produits pour, dans un premier temps, dépasser gcc puis se rapprocher des compilateurs Intel, le support de OpenMP (en cours de développement) et le support de Fortran.

    Lire les commentaires

  • Parcittox, le gestionnaire de presse-papier en réseau (Journaux LinuxFR)

    J'ai le plaisir de vous présenter Parcittox, un fork de Parcellite et de Ditto.

    Initialement, un gestionnaire de presse papier (Clipboard_manager) est un petit utilitaire qui permet d'avoir un historique du presse papier et d'intervertir la sélection et le Ctrl + C. Il en existe quelque uns sous Linux tels que Parcellite, Klipper ou Glipper. C'est extrêmement pratique. Vraiment.

    Sur Windows, il existe l'excellent Ditto qui possède en plus la possibilité d'échanger les clips entre plusieurs machines en réseau. Travaillant justement avec plusieurs machines, sous Linux et sous Windows, je me devais donc de porter cette fonctionnalité indispensable et c'est chose faite !

    Pour les ramollos du lobe frontal :

    • je sélectionne du texte sur mon PC Linux,
    • win + V sur mon PC Windows,
    • je choisis le dernier clip venant d'être reçu,
    • le même texte est inséré dans mon application Windows,
    • et je ne m'extasie pas, car c'est la 6 452ème fois de la journée que je le fais.

    Dittox est une bibliothèque C implémentant le protocole réseau de Ditto, et Parcittox est le fork de Parcellite utilisant cette bibliothèque, ainsi que quelques ajouts comme QRencode.

    Ce qui nous donne les fonctionnalités initiales suivantes :

    • historique des deux presse-papiers
    • sauvegarde de l'historique
    • liste persistante de clips
    • édition de chaque clip
    • un truc à propos d'Actions dont je me cogne le bambou

    Et avec Parcittox :

    • échange chiffré des clips en réseau
    • support IPv4 et IPv6 (non testé, donc à mon avis ça ne marche pas…)
    • pas mal d'options et de notifications pour gérer les erreurs réseau
    • affichage du clip sous forme de QR code pour votre téléphone portable malin
    • correction et rajout de différents bugs par rapport à Parcellite

    Pour essayer :
    svn co https://subversion.assembla.com/svn/dittox/trunk/parcittox

    La compilation utilise les bloattools autotools, plus d'infos sur la page du projet :
    autogen.sh / configure / make

    Une fois lancé, win + P pour configurer la bestiole, win + V pour choisir les clips et bouton droit ou flèche droite pour accéder au sous-menu-surgissant de chaque clip. Normalement, il y a une icône qui devrait s'afficher dans la barre de menu, mais chez moi, ça ne le fait plus et je ne veux pas savoir pourquoi.

    Il n'y a pas de paquets, désolé. Et ne comptez pas trop sur moi pour en faire… ou encore corriger des bugs, ou rajouter des fonctionnalités, ou porter Dittox à un autre gestionnaire. Enfin pas avant 2046.

    Dittox / Parcittox : http://www.assembla.com/spaces/dittox/wiki
    Parcellite : http://parcellite.sourceforge.net/
    QRencode : http://fukuchi.org/works/qrencode/

    Lire les commentaires

  • Déclaration de dépendance du cyberspace (Journaux LinuxFR)

    Coucou joujou,

    Après le troll réussi sur l'auto-hébergement, initialement publié sur mon blog, puis largement commenté ici (centralisation oblige), voilà une autre traduction sur la dépendance du cyberespace au monde physique, moins polémique je l'espère. J'ai copié le texte ci-dessous pour ne pas faire seulement bookmark, mais n'hésitez pas à parcourir les autres contenus du blog et à commenter/participer.

    Il y a quelques années, en 1996 (les vieux du village s'en souviendrons peut-être), John Perry Barlow a écrit la Déclaration d'indépendance du cyberespace. Ce document a été largement regardé par l'élite numérique comme la pierre angulaire de tout ce qui touche Internet.

    Ce document proclamait l'indépendance du monde physique de ce tout nouveau cyberespace. Les gouvernements, leurs restrictions, règles et régulations n'y auraient pas leur place. Une telle pensée traverse toujours beaucoup d'articles et d'essais sur la nature d'Internet et son but.

    Lorsque nous arrivons sur une page web à accès géographiquement restreint nous ressentons l'influence des lois du monde physique dans lequel nous vivons alors que dans le monde numérique les 0 et 1 semblent circuler librement. Il nous semble alors que ces lois sont caduques et que le cyberespace ne devrait pas être ainsi cassé, dénaturé. Ce qui est intéressant c'est que cette impression est erronée.

    L'indépendance du cyberespace a été acclamée avec enthousiasme pour deux raisons simples :

    • Les lois que nous trouvions stupides dans le monde physique nous semblaient ici aussi stupides. (Je rappelle aux plus vieux d'entre nous que les disques japonais avaient rarement le même contenu au Japon et aux États-Unis.)
    • Les gens qui pensaient comme nous étaient en ligne et les autres n'y étaient pas.

    Le cyberespace était plein de gens doués, créatifs. Des artistes, des scientifiques, des hackers. Basiquement l'antithèse des foules consuméristes qui débarquèrent après et que l'on avait appris à mépriser. Avec ceux qui étaient en ligne, tout semblait possible. Les utopies semblaient à portée de main. L'ère des super-héros allait arriver. La singularité était une affaire de semaines.

    Bien sûr, cela ne s'est pas passé comme ça.

    À un moment, Internet devint grand public. Comme l'écriture ou le jazz. Lorsque nous recevions tous les jours un nouveau pack de disques AOL dans notre boîte aux lettres nous aurions dû nous en rendre compte.

    Il y a quelques années un procureur a demandé au porte-parole de The Pirate Bay Peter Sunde s'il avait déjà rencontré ses collègues «dans la vraie vie», Peter répondit :

    Nous n'aimons pas l'expression « Dans la vraie vie ». Nous disons « Loin du clavier ». Nous pensons qu'Internet est réel.

    Peter ne pouvait voir plus juste. Internet est réel. Le monde physique est réel aussi. Prétendre qu'il y a là deux facettes indépendantes de la réalité même si nous circulons sans cesse de l'une à l'autre en ne faisant rien de plus que vivre est au mieux étrange et au pire schizophrénique.

    Quand dans Internet il n'y avait que des groupes de discussions, des canaux IRC et des sites webs avec des gifs animés qui disaient « Envoyez moi un mail », les deux mondes semblaient distincts et indépendants. Mais à présent, regardez autour de vous.

    La moitié des appareils de la pièce où je suis sont connectés à Internet d'une manière ou l'autre. Bientôt vos plantes auront des comptes Twitter qui vous diront quand les arroser. Nous empilons les couches de données sur le monde physique. Ces données nous connectent et nous repèrent sur cette boule de poussière qui roule dans l'espace. Votre téléphone ne se contente pas de vous dire comment se déroule les manifestations en Turquie et au Brésil mais sait aussi parfaitement où vous êtes et vous permet d'éviter de manger dans ce joli petit resto pour préserver votre estomac.

    Internet n'est pas fait d'idées ou d'éther. Il est fait de câbles de métal et de fibres de verre ou plastique. De même que nous sommes coincés dans nos corps de chair, Internet est essentiellement coincé dans des datacenters, des usines à données. C'est une perspective différente sur la réalité, qui ouvre d'autres manières de communiquer. Certaines sont formidables et d'autres sont horribles (les forums je pense à vous). Elle augmente exponentiellement nos capacités humaines en nous permettant de voir un nombre quasi infini de vidéos de chatons.

    Le cyberespace dépend du monde physique de même que le monde physique, nos infrastructures et industries, ont désormais besoin d'Internet pour fonctionner. Le cyberespace et le monde physique sont entretissés et il est temps d'arrêter de les regarder comme des ennemis.

    Certes, Internet nous a montré que beaucoup de lois sont stupides. Mais elles ne sont pas stupides que sur Internet. Elles sont stupides en général. Ce n'est pas à cause d'Internet qu'elles ont besoin d'être changées mais pour des raisons plus générales.

    À présent la singularité semble être retournée dans les limbes de l'avenir. C'est bien. Nous avons perdu l'entre-soi de nos petits cercles d'amis qui connaissaient nos protocoles tout personnels. En échange nous avons gagné le potentiel d'embarquer toute l'humanité dans l'aventure, en leur montrant les possibilités infinies que nous avons explorées avant eux.

    Je n'ai jamais pensé qu'Internet était le salut d'une petite élite. Je crois qu'en faisant sienne la connexion profonde et indépassable entre le monde des données numériques et le monde physique, nous pouvons construire un monde meilleur pour tous. C'est tout ce qui compte, n'est-ce pas ?

    Lire les commentaires

  • Install Party le 29 Juin 2013 à Marseille (Dépêches LinuxFR)

    L’association CercLL « CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres » organise une install party de 14h00 à 18h00 le 29 Juin 2013 au Bistrot des Anges, 2 boulevard de Pont de Vivaux, 13010 Marseille (parking assuré, lignes de bus 15, 18 et 91).

    Vous avez envie de découvrir un système d’exploitation libre, simple d’utilisation, stable, rapide et sécurisé ? Une nouvelle façon d’utiliser votre ordinateur ? Vous vous sentez une affection naissante pour le gnou et le manchot, les mascottes de GNU/Linux ?

    Au programme :

    • découverte de l’univers des logiciels libres ;
    • installation d’un environnement GNU/Linux, ainsi que le meilleur des logiciels libres.

    Venez avec votre ordinateur : nous installerons ensemble une distribution GNU/Linux avec un ensemble de logiciels libres et gratuits pour une utilisation quotidienne.

    Entrée libre – accessible aux débutant-e-s.

    Contact : cercll13@gmail.com

    poster promotionnel

    Lire les commentaires

  • Sortie de PulseAudio 4.0 (Dépêches LinuxFR)

    PulseAudio est un serveur de son multi‐plate‐forme développé en C et publié sous licence LGPL 2.1. Son rôle au sein d’un système d’exploitation est d’effectuer le mixage des canaux audio en provenance des diverses applications et entrées sonores externes, puis leur lecture sur des périphériques audio tels que des cartes sons locales ou distantes (voir les schémas ici et là).

    La version 4.0 est sortie le 3 juin (et est déjà disponible dans Debian Sid, par exemple).

    Logo PulseAudio

    Rappelons que PulseAudio, devenu le serveur de son de référence pour les systèmes GNU/Linux, a été créé par le très talentueux Lennart Poettering :

    De nos jours les vendeurs de matériel comprennent que quand PulseAudio ne marche pas correctement avec leurs produits c’est sans doute de leur faute, pas celle de PulseAudio. D’une certaine façon, PulseAudio est devenu un test standardisé que les vendeurs de matériel utilisent pour évaluer leurs pilotes. (source)

    Lennart Poettering

    Les principales nouveautés

    • Meilleure gestion des demandes pour les flux nécessitant une faible latence ;
    • Optimisations du mixage des flux audio (générique, ARM NEON) ;
    • Le rééchantillonnage utilise maintenant par défaut une qualité de 1/10 plutôt que 3/10, et permet ainsi d’alléger la charge processeur sans perte de qualité notable ;
    • Factorisation du code pour le Bluetooth permettant une meilleure fiabilité et une maintenance plus simple ;
    • Complétion Bash et zsh pour les outils en ligne de commande ;
    • Correction de bogues pour Solaris et Mac OS X ;
    • Ajout du MPEG-2 AAC pour le matériel le prenant en charge ;
    • Beaucoup d’autres améliorations, corrections de bogues, documentation et mises à jour d’internationalisation.

    Les nouveaux modules

    module-role-ducking

    Ce module permet d’adapter les niveaux sonores des différents flux en fonction de leur importance (ducking). Par exemple, par défaut, les flux audio et vidéo sont relégués au second plan lorsque un flux téléphone est présent. Ce comportement utilise les propriétés media.role des flux. Ce module n’est pas activé par défaut.

    module-remap-source

    module-remap-source permet d’encapsuler une source pour réassigner ses ports. Par exemple, il est possible de permuter les canaux droit et gauche.

    Lire les commentaires

  • Voyager en Inde en moto (Journaux LinuxFR)

    Coucou journal,

    Très hors sujet, mais l'année dernière j'ai été 4 mois en Inde en moto (et j'y repars dans quelques jours), et on a fait un montage video à https://vimeo.com/68517374 de quelques minutes, sur comment je voyage quand je voyage. Bon ça risque d'être un peu long mais qui sait, ça vous fera une pause midi :) Y a des détails mais en Anglais.

    Lire les commentaires

  • Le combat X contre Wayland : les faits vus par Eric Griffith (Dépêches LinuxFR)

    Voici la traduction (avec quelques libertés) d’un article paru sur Phoronix sous licence CC-By-3.0.

    Introduction

    Un aperçu des problèmes, corrections et fonctionnalités liés à X et Wayland. Écrit par Eric Griffith, avec l’aide de Daniel Stone (développeur X.Org et Wayland). Corrigé et validé par Daniel Stone.

    Cet article a été rédigé par un contributeur volontaire de Phoronix en se basant sur des présentations de Keith Packard, David Airlie, Daniel Stone, Kristian Høgsberg ; ainsi que les wikis de X11, X12, Wayland et Freedesktop.org, et des questions‐réponses directes avec les développeurs.

    Depuis sa première annonce, il y a plusieurs années, il y a eu beaucoup d’informations, de désinformation, de fausses idées, et du pur FUD à propos de Wayland, le remplaçant de nouvelle génération du système de fenêtrage X. Cette présentation a pour but de clarifier la situation de Wayland.

    L’article est très inspiré par la récente conférence technique donnée par Daniel Stone à la conférence Linux australienne linux.conf.au de 2013, à laquelle il constitue une excellente introduction. L’anglais de Daniel Stone est facilement accessible, sa conférence complète excellemment l’article, et ses diapos sont un modèle d’humour. Allez la voir, c’est hilarant, très instructif et puis il est une des rares personnes qui connaît vraiment le sujet.
    Elle est disponible au format Ogg vidéo ou sur un site de partage de vidéos bien connu.

    Sommaire

    Les lacunes de X

    Personnellement, je pense que les bénéfices et le but de Wayland sont mieux compris quand ils sont comparés aux erreurs et lacunes de X. Donc, commençons…

    Les premières années

    Nous avons passé les 10 dernières années ou presque à « corriger » le serveur X en empilant de plus en plus d’extensions et de greffons. Le problème est que X n’a qu’un système de gestion de versions très limité pour ses extensions.

    1. La gestion de versions est gérée par client, et non par lien. Donc, si votre application prend en charge une version d’une extension donnée, mais que votre bibliothèque graphique en gère une autre, vous ne pouvez pas prévoir quelle version de l’extension vous allez obtenir.
    2. Un exemple théorique : Rekonq gère XInput 2.2, KDELibs prend en charge XInput 2.0 et le greffon Flash ne gère que X11 Core… Tous ceux‐là vont se battre pour décider quelle version du système d’entrée Rekonq prend en charge et à la fin, vous aurez une version qui s’occupera de tout le monde… Qui ne sera peut‐être pas la version que tout le monde prend en charge.
    3. Si vous avez de la chance, vous recevrez la plus basse version prise en charge et tout fonctionnera correctement. Si vous n’avez pas de chance, vous recevrez la plus haute version prise en charge et vous échangerez des données inutiles qui conduiront potentiellement à des erreurs entre le client et le serveur X.

    Les 4 mousquetaires des entrées

    X a quatre sous‐systèmes d’entrée : Core X11, XInput 1.0, XInput 2.0 et XInput 2.2. XInput 1.0 a été éliminé, mais les trois restants sont plus inter‐dépendants qu’indépendants. Comme Daniel Stone l’a dit : « Il y a à peu près 3 personnes qui comprennent VRAIMENT comment les sous‐systèmes d’entrée tiennent ensemble… Et j’aurais vraiment souhaité ne pas être l’un d’eux. »

    La politique ?

    Il y a de nombreuses années, quelqu’un a eu une idée : « technique, et non pas politique ». Qu’est‐ce que ça veut dire ? Cela veut dire que X a sa propre API de dessin, il est sa propre bibliothèque graphique, comme GTK+ ou Qt. Il définit les éléments de bas niveau, tels que les lignes, les lignes larges, les arcs, les cercles, les polices rudimentaires, et autres « blocs de construction » qui sont complètement inutiles pris séparément. Note de Daniel : « Histoire drôle : les lignes larges doivent respecter au pixel près la spécification, mais cette dernière les définit moches. »

    Bibendum

    Le serveur X est énorme et stupide. Avant que nous (la communauté) commencions à lui retirer des morceaux et travailler dessus, c’était presque un système d’exploitation complet.

    1. Vous ne me croyez pas ? X avait son propre serveur d’impression. Il a été supprimé après que quelqu’un a ajouté la prise en charge de Xprint à glxgears.
    2. C’était un interpréteur binaire pour ELF, COFF et a.out.

    La composition et la cohérence des fenêtres

    Composition et cohérence des fenêtres. Les développeurs ont appris à X la composition à travers l’extension Composite. Pour les choses simples, comme le bureau, la composition OpenGL est utilisable. Si vous voulez une couche utilisant l’accélération matérielle (comme la vidéo), cela devient un désastre complet.

    Cohérence des médias. Qu’est‐ce que c’est ? En termes simples… Votre fenêtre de navigateur ? C’est une fenêtre. Votre lecteur Flash sur YouTube ? Le lecteur Flash lui‐même, affichant la vidéo, est une sous‐fenêtre. Qu’est‐ce qui garde ces deux fenêtres synchronisées ? Absolument rien. Les événements sont gérés séparément et actuellement vous priez pour qu’ils ne soient pas traités à des moments trop éloignés. Ce qui explique pourquoi quand vous faites défiler une page YouTube, ou un autre site où une vidéo est jouée, parfois tout se sépare en morceaux.

    Les polices de caractères

    Les développeurs ont essayé d’apprendre au serveur X à utiliser les polices grâce à l’extension STSF. L’idée était de stocker les polices du côté du serveur, et de donner aux clients suffisamment d’informations pour qu’ils puissent générer l’agencement de la police tout seuls. Les informations nécessaires pour ça se sont révélées plus importantes que la taille de la police. Il a donc été décidé d’envoyer la police directement au client et de laisser ce dernier se débrouiller avec.

    La gestion des états (ou plutôt son absence)

    Absence d’états… En d’autres mots : X ne se souvient de rien !

    1. « Génère‐moi un fichier de configuration… En fait, utilise celui‐ci. » Pourquoi ? Finalement corrigé en faisant en sorte que le serveur X n’utilise qu’un seul fichier de configuration pour les exceptions, et qu’il connaisse et intègre des options par défaut sensées, ainsi que de l’auto‐détection.
    2. Qui n’a jamais eu de problèmes avec le multi‐écran sous Linux ? Ou alors, qui n’a jamais vu la configuration de tous ses moniteurs disparaître après un redémarrage ? C’est de la faute de X, sauf si vous sauvegardez votre configuration dans /etc/X11/xorg.conf.d/50-monitors.conf, et alors il s’en souvient… Mais vous avez probablement dû écrire ça à la main.
    3. Avec un peu d’optimisme, cela sera corrigé par la création de libkscreen, un « enrobage logiciel » — wrapper — pour xrandr se souvenant de l’emplacement de chaque écran grâce à son EDID qui est unique.
    4. Depuis longtemps, et c’est peut‐être encore le cas, quand vous branchez un moniteur supplémentaire alors que l’écran primaire a une composition, il se peut qu’elle n’apparaisse pas sur celui nouvellement ajouté. Cela peut avoir été corrigé par RandR 1.4, mais l’auteur ne peut clairement affirmer si ce problème est résolu.

    L’arborescence des fenêtres

    L’arbre des fenêtres est un bazar complet. Avec X, tous les champs de saisie et boîtes de texte sont une fenêtre ayant comme parent la fenêtre contenante. C’est pourquoi personne ne comprend la fonction qui valide l’arbre des fenêtres. Les vraies (par exemple, pas Core X11) boîtes à outils graphiques — toolkits — ont jeté ce fonctionnement par la fenêtre depuis longtemps. Sans jeu de mots.

    Le compteur de pixels

    C’est un détail, mais aussi un reproche recevable… Avec X11, le compteur total de pixels est de 15 bits. En conséquence, le nombre maximal de pixels autorisé, tous affichages confondus, est de 32 768. À 100 ppp, cela fait un affichage de 8,3 mètres. Super… En comparaison, en revanche, Windows XP a 96 ppp. Mon téléphone a 320 ppp. Ajoutez de plus grandes définitions et des moniteurs multiples, et les choses deviennent vite hasardeuses.

    Tout est fenêtre

    Tout est fenêtre dans X. Il n’y a pas de différents types de fenêtre, juste « une fenêtre ».

    1. Votre économiseur d’écran ? C’est une fenêtre qui a dit à X :
      1. mets‐moi au-dessus de toutes les autres fenêtres, tout le temps ;
      2. mets‐moi en plein écran ;
      3. donne‐moi toutes les entrées utilisateur — focus.
    2. Une fenêtre surgissante — popup — ? C’est une fenêtre qui a dit à X :
      1. Mets‐moi ici ;
      2. Donne‐moi toutes les entrées utilisateur — focus.
    3. Problème ? Pour commencer : les fenêtres se contredisent. L’économiseur d’écran ne s’activera pas tant qu’il y aura une fenêtre surgissante à l’écran, car elles entrent en conflit.
    4. Votre économiseur‐verrouilleur d’écran n’a probablement pas fait les liens avec toutes les bibliothèques pour gérer les touches multimédia… Le problème vient de la situation suivante : vous êtes en train de travailler chez vous, avec de la musique. Vous fermez le capot de votre portable pour le mettre en veille. Après cette opération, l’écran de verrouillage est la fenêtre active. Quand l’ordinateur est réactivé, la musique reprend aussitôt sur les haut‐parleurs, et il est plus facile pour vous de refermer le capot que de taper le mot de passe, ouvrir le lecteur multimédia pour le mettre en pause ou mettre l’ordinateur en muet.
    5. Les développeurs ont essayé de corriger ce problème. Ils ont défini une extension, avec une théorie toute prête, mais quand est venu le moment de l’implémenter, ils ont constaté qu’elle briserait le fondement du modèle de X. C’est un problème depuis 26 ans, et ça le restera. Appréciez.

    Alors pourquoi pas X12, comme suite au vénérable X11 ?

    « Mais, Eric, si X11 est si mauvais, pourquoi ne pas faire X12, plutôt que de définir un nouveau protocole ? » Ils l’ont fait, techniquement, du moins : http://www.x.org/wiki/Development/X12.

    Un des principaux problèmes rencontrés en conservant l’appellation X est que quiconque s’occupant de X va vouloir avoir son mot à dire sur la version suivante. En l’appelant Wayland, ils (les développeurs) évitent ce problème. Personne ne s’en préoccupe. Cela peut être un projet différent, ils peuvent faire ce qu’ils veulent avec leur futur serveur d’affichage, les gens se souciant de X peuvent faire X12 de leur côté.

    Les corrections de Wayland

    Les corrections sont traitées dans l’ordre des « problèmes » de X11 listés ci‐dessus.

    Tout le protocole est versionné

    Tout le protocole est versionné. Chaque auditeur — listener — reçoit exactement la version qu’il prend en charge, pas plus. Plus d’aléatoire.

    La gestion des entrées

    Le système d’entrées de Wayland ressemble beaucoup à XInput 2.2, moins toutes les cochonneries d’héritage et moins la relation maître‐esclave entre les entrées. Tout le monde reçoit un clavier virtuel, une souris virtuelle et une interface de tablette non virtuelle. Le cauchemar appelé multitouch (multi‐tactile) sera enfin réglé. Note de Daniel : « En tant qu’un des auteurs du multitouch, je me sens bien qualifié pour dire que c’est de la merde. »

    Absence d’API de « dessin »

    Wayland n’a aucune API de dessin, évitant ainsi de s’emmêler les pinceaux. Wayland veut recevoir des tampons remplis de pixels de la part des clients et, à part les vérifications de sécurité pour éviter qu’un client n’agisse sur la mémoire tampon — buffer — d’un autre, il se contrefiche de savoir comment les pixels sont arrivés là. Les clients contrôlent quels pixels sont dans quelles mémoires tampon, et ainsi ce qui sera affiché sera exactement ce que le client voulait.

    Minimalisme

    Wayland est minimal. Il n’y a pas de pseudo système d’exploitation surchargé contrôlant la carte graphique. Il n’y a pas une API vieille de 26 ans qui empêche les évolutions. Les clients se chargent du travail, ce qui est une bonne chose parce que les clients n’ont pas à maintenir une rétro‐compatibilité extrême. Qt5 a laissé tomber les classes de compatibilité avec Qt3, X doit toujours maintenir des choses écrites il y a 26 ans. Et les choses d’il y a 26 ans se mettent en travers du chemin des corrections de problèmes actuels.

    Note de Daniel : « Wayland est aussi non bloquant, ce qui fait que votre bureau entier n’arrêtera pas son rendu uniquement parce qu’un client est en train de faire une opération longue. Seul ce client arrêtera son rendu. »

    Composition

    La composition est requise sous Wayland. Ça ne veut pas dire que tout a besoin d’effets 3D ou de fenêtres molles. La composition veut dire que tout se fait sans scintillement, sans mise en pièce. La devise de Wayland est « chaque image est parfaite ». Chaque pixel est exactement ce qu’il doit être où il doit être, et là quand il doit y être — tel que demandé par le client.

    Les polices de caractères

    Les logiciels clients s’occupent des polices de caractères, comme ils le font déjà, en fait.

    Gestion du multi‐écran

    Le multi‐écran est un problème du client. Même chose en ce qui concerne les cartes graphiques multiples (Optimus). Wayland désire uniquement des mémoires tampons remplies avec des pixels, et qu’on lui dise où les afficher. Il ne se tracasse pas de comment ils sont apparus là.

    Plusieurs types de fenêtres

    À l’inverse de X, dans lequel tout était fenêtre, Wayland gère deux types de fenêtres différents. Les fenêtres de niveau supérieur, qui sont essentiellement des conteneurs de multiples tampons, et les fenêtres de sous‐niveau, principalement pour les lecteurs vidéo.

    Néanmoins, tout cela est maintenu cohérent, à l’opposé de X, en évitant les défauts de couleur et autres artefacts générés lorsque vous descendez sur les commentaires d’une vidéo YouTube pendant que celle‐ci est en cours de visionnage.

    Un autre système de positionnement de pixel

    Wayland ne gère pas les coordonnées globales, du moins, pas publiquement. Il gère des coordonnées relatives pour les surfaces. Le compteur de coordonnées de Wayland fait une taille de 31 bits, cela veut dire que chaque surface (c.‐à‐d. fenêtre) peut avoir une taille de 2 147 483 648 pixels.

    Une précaution de sécurité

    Pour des raisons de sécurité, votre écran de veille et de verrouillage fait partie du compositeur. Cela a pour effet bénéfique que votre compositeur (par exemple, KWin) comprend les touches multimédia, donc, vous pouvez mettre votre ordinateur en sourdine, même quand votre écran est verrouillé.

    Quelques idées reçues sur X et Wayland

    X respecte la philosophie UNIX

    La philosophie Unix dit qu’il faut faire une seule chose et la faire bien. X gérait l’impression, les mémoires tampon et les polices, il avait sa propre bibliothèque graphique, il était un interpréteur binaire, parmi bien d’autres choses. Quelle est cette chose unique que X faisait et qu’il faisait bien ?

    X supporte la transparence réseau

    Faux. Ce n’est pas le cas. Core X et DRI-1 supportaient la transparence réseau. Plus personne ne les utilise. La mémoire partagée, DRI-2 et DRI-3000 ne supportent pas la transparence réseau, ils ne fonctionnent pas sur le réseau. De nos jours, X se résume à être un VNC synchrone et appauvri. S’il avait été fait différemment, c’est‐à‐dire asynchrone, alors nous pourrions peut‐être le faire fonctionner. Mais ça n’est pas le cas. Xlib est synchrone (et le mouvement vers XCB est lent), ce qui fait du réseautage un cauchemar.

    Les développeurs de Wayland recréent X11 car ils ne l’ont pas compris

    Faux. La plupart des développeurs de Wayland sont des ex‐développeurs de X11. Ils savent à quel point il est horrible. Ils savent où sont ses faiblesses. Ils veulent faire mieux que X11.

    Wayland nécessite la 3D

    Faux. Il nécessite la composition, mais ça n’est pas forcément de la 3D. Rien dans Wayland ne nécessite la 3D, il y a même un rendu logiciel utilisant la bibliothèque de manipulation d’images Pixman.

    Wayland ne fait pas de session à distance

    Faux. Wayland devrait être meilleur que X pour l’affichage à distance, cela étant en partie dû à sa nature asynchrone par conception. L’affichage distant de Wayland ressemblera probablement à une version plus performante de VNC. Un prototype existe déjà, et cela sans réfléchir sérieusement à la manière de l’améliorer. Nous pourrions sûrement faire mieux si nous avions essayé.

    Wayland casse la gestion des bureaux de tout le monde

    Toujours faux. Une fois que XWayland sera terminé et intégré, nous devrions avoir plus ou moins une compatibilité ascendante parfaite, parce que chaque application X reçoit son propre mini‐serveur X avec lequel elle peut dialoguer. Il y a un problème connu qui est lié aux transformations de fenêtres, parce que chaque application pense qu’elle est dans le coin supérieur droit de l’écran (youpi les coordonnées globales) et que chaque mini‐serveur X est verrouillé à la taille de la fenêtre de son client.

    Quelques avantages génériques de Wayland

    Chaque image est parfaite

    Le but principal de Wayland est que quelle que soit la charge du système, quoi qu’il se passe, il ne doit pas y avoir de scintillements, de déchirures ou de flashs. Chaque image est présentée dans l’ordre correct et approprié (sauter des images est accepté, mais vous n’aurez pas l’image 199, suivie de la 205, suivie de la 200, parce qu’elles ont toutes été envoyées à peu près au même moment et que le serveur les a prises au hasard). Wayland sait dans quel ordre elles viennent, dans quel ordre il faut les afficher, et quand elles ont été affichées, car tout est associé à un horodatage.

    Wayland est minimal

    Nous avons appris à la dure ce qui arrive quand vous avez quelque chose qui fait beaucoup de choses et qui doit aussi maintenir la compatibilité ascendante —— nous nous mordons toujours les doigts pour des erreurs commises il y a 26 ans dans X. Laissons les clients gérer les choses, ils peuvent changer, ils peuvent casser autant de choses qu’ils veulent parce que ce sont eux qui doivent gérer les retombées de la casse. Nous aidons à rendre Wayland résistant au futur en réduisant la surface d’attaque des erreurs.

    Des back‐ends spécifiques pour chaque matériel

    Je suis sûr que certains ont vu que le Raspberry Pi a reçu un back‐end spécifique pour Wayland, et comme cela a permis de mieux tirer parti du matériel. Ce ne sera pas nécessaire à chaque fois, la plupart des matériels ne nécessiteront pas un back‐end spécifique… Mais il est sûr que c’est sympa que ce soit disponible. Cela veut dire qu’on a la liberté, on a le choix de faire des adaptations spécifiques si on le désire. Ou, si on réalise en cours de route que le back‐end principal a des défauts de conception, on peut le changer par un autre qui n’en a pas.

    ~Fin~

    Lire les commentaires

  • Ayé, on peut compiler Firefox pour GTK+3 (si on veut) (Journaux LinuxFR)

    Firefox

    Voilà.

    Merci notamment à Martin Stránský (Red Hat).

    Lire les commentaires

  • Debian 7.1 est sortie, mise à jour de securité pour Debian 7.0 (Wheezy) (Dépêches LinuxFR)

    Le projet Debian a l'honneur d'annoncer la première mise à jour de sa distribution stable Debian 7 (nommée « Wheezy »). Tout en réglant quelques problèmes importants, cette mise à jour corrige principalement des problèmes de sécurité de la version stable. Les annonces de sécurité ont déjà été publiées séparément et sont simplement référencées dans ce document.

    Veuillez noter que cette mise à jour ne constitue pas une nouvelle version de Debian 7 mais seulement une mise à jour de certains des paquets qu'elle contient. Il n'est pas nécessaire de jeter les CD et DVD de la version 7 mais simplement de faire une mise à jour à l'aide d'un miroir Debian après une installation, pour déclencher la mise à jour de tout paquet obsolète.

    Ceux qui installent fréquemment les mises à jour depuis la version 7.0 à partir de security.debian.org n'auront pas beaucoup de paquets à mettre à jour car ils ont déjà effectué la plupart des mises à jour de cette version 7.1.

    De nouveaux supports d'installation et des images de CD et de DVD contenant les paquets mis à jour seront prochainement disponibles à leurs emplacements habituels.

    La mise à jour en ligne vers cette version se fait en faisant pointer l'outil de gestion des paquets aptitude (ou apt) (consultez la page de manuel sources.list(5)) sur l'un des nombreux miroirs FTP ou HTTP de Debian. Une liste complète des miroirs est disponible à l'adresse :
    http://www.debian.org/mirror/list

    Rappel :
    La version 7.0 Wheezy, version stable, est sortie le 4 mai 2013. Elle inclut les éléments suivants :

    • noyau Linux 3.2 ; -X-server : X.Org 7.7 ;
    • GNOME 3.4 ;
    • KDE 4.8.4 ;
    • Xfce 4.8 ;
    • Libc : eglibc 2.13 ;
    • apt 0.9.7 ;
    • plus de 36000 autres paquets.

    D'une manière générale la sécurité est réputée être un point fort de Debian. La politique de sécurité (commune aux systèmes libres) est de toujours afficher les failles de sécurité découvertes. Une équipe spécialisée dans la sécurité de l'ensemble des logiciels proposés sur Debian est d'ailleurs une référence dans ce domaine et participe activement au comité « Open Vulnerability Assessment Language »

    De plus, pour la première fois, Debian Wheezy permet les fonctionnalités suivantes :

    • prise en charge du multiarchitecture ;
    • gestion de l'UEFI pour l'installation ;
    • installation via synthèse vocale (plus d'une douzaine de langues supportées, l'installateur normal peut être affiché dans 73 langues).

    Même Linux Mint, une distribution majeure par sa popularité, possède une version Debian, c'est dire la qualité reconnue de cette distribution qu'est Debian.

    Lire les commentaires

  • Sous le capot de la beta LibreOffice 4.1 (Dépêches LinuxFR)

    Michael Meeks est un hacker qui travaille sur la suite bureautique LibreOffice pour l'éditeur SUSE.

    Logo LibreOffice

    Il vient de publier sur son blog une longue introduction à certaines nouveautés méconnues de la version 4.1 de LibreOffice. Comme ce texte est fort intéressant et qu'il est placé dans le domaine public (et sous licence CC0 quand la législation locale interdit à un auteur d'opter pour le domaine public) il m'a semblé pertinent de traduire son post.

    Vous trouverez donc dans la suite de la dépêche une traduction du texte de Michael.

    Sommaire

    Sous le capot de la Beta LibreOffice 4.1

    Nous allons sortir LibreOffice 4.1 très bientôt - en ce moment nous sommes en phase Beta et nous apprécierions que des gens aident pour les tests. Vous pouvez télécharger les builds depuis les pré-versions ou bien, si vous préférez les trucs très frais, depuis les dev-builds.

    Nous sommes encore en train de rédiger la liste complète des nouveautés et des remerciements. Bien entendu nous avons déjà un certain nombre de nouveautés visibles ici avec les crédits associés. Cor a écrit une paire d'entrées sur son blog à propos des améliorations de l'interface et de la fonction d'album photo qui seront intégrés dans cette 4.1.
    Cela m'a fait penser aux nombreux développeurs qui ont travaillé extrêmement dur sur des choses qui sont sous le capot, qui ne sont pas vraiment visibles mais qui sont pourtant vraiment importantes. Je voudrais expliquer ici certaines de ces nouveautés (en créditant l'employeur du développeur quand il y en a un). Souvent ce sont des choses assez simples et qui semblent triviales quand on les regarde isolément mais, prises ensembles, elle donnent une base de code qui est bien plus simple à aborder et sur laquelle on peut contribuer plus facilement.

    Build system: configure / make

    Depuis des années l'une des tâches qui irritent et qui bloquent le plus les nouveaux développeurs voulant travailler sur la base de code est notre système de build. Au démarrage de LibreOffice il y a eu une transition incomplète vers GNU make ce qui nous a obligé à utiliser à la fois l'horrible dmake ainsi que gnumake avec configure utilisant un script Perl pour générer un script shell configurant un ensemble de variables d'environnements qui doivent être utilisées dans votre shell pour que ça compile (ce qui rend impossible la reconfiguration depuis ce shell). Il y a également un script de build en Perl qui fait de la compilation en batch avec deux niveaux de parallélisme.
    Au final ça ressemble à un truc comme ça:

    Le vieux système bien horrible

    autoconf
    ./configure --enable-this-and-that
    source LinuxIntelEnv.Set.sh
    ./bootstrap
    cd instsetoo_native
    build --all

    Grâce aux efforts enthousiastes de Björn Michaelsen (Canonical), David Tardon (Red Hat), Peter Foley, Norbert Thiebaud, Michael Stahl (Red Hat), Matúš Kukan, Tor Lillqvist (SUSE), Stephan Bergmann (Red Hat), Luboš Luňák (SUSE), Caolán McNamara (Red Hat), Mathias Bauer (Oracle), Jan Holesovsky (SUSE), Andras Timar (SUSE), David Ostrovsky, Hans-Joachim Lankenau (Oracle) et d'autres—(plus de details) les 126 000 cibles et les 1 700 makefiles sont maintenant complètement convertis vers GNU make. Cela permet d'utiliser la syntaxe suivante qui est bien plus simple:

    Le configure & make actuel pour LibreOffice

    ./autogen.sh --enable-this-and-that
    make

    Plus de pollution de shell, plus de script de « bootstrap », plus de wrapper Perl, plus de vieux « dmake » sur le chemin. Que des fichiers GNU make classiques —avec un niveau incroyable de parallélisme puisqu'après la génération des headers, nous pouvons utiliser des milliers de processeurs.
    C'était un boulot bien précis avec un objectif bien spécifié, comme le processus de retrait du code mort que nous avons effectué dans les versions précédentes, et c'est maintenant terminé. Cela libérera les développeurs qui pourront faire des trucs plus intéressants par la suite.

    Graphique de gnumake vs. dmake par version

    Système de Build: make dev-install

    LibreOffice, contrairement à beaucoup d'autres logiciels, est entièrement re-localisable : vous le balancez où vous voulez, et l'exécutez à partir de là. Nous utilisons un make-dev-install pour créer une installation dans install/ que vous pouvez exécuter dans l'arbre de compilation. Ce processus était traditionnellement effectué par un script Perl utilisant un ensemble compliqué de règles pré-traitées, pour réaliser ce qui est (essentiellement) une opération de copie. David Tardon a fait le gros travail de bouger ça vers l'utilisation de listes de fichiers qu'on génère automatiquement. Donc, aujourd'hui, nous avons un instdir/ top-niveau (sur lesquelles opèrent ces listes de fichiers) qui commence à refléter l'install : l'idée étant que la phase make install tourne à l'intérieur de l'arbre de compilation. Jusqu'à présent, nous avons plus de 250 listes de fichiers, gérant près de 20k fichiers.

    Cette initiative facilite grandement l'ajout ou la suppression de fichiers d'installation, et élimine un tas de zip/unzip de jeux de fichiers utilisés pendant la compilation, accélérant le packaging et la compilation : Le packaging du SDK est passé de 90 secondes à environ 30 secondes, en éliminant plein de règles scp2/. L'espoir est que lorsque ce sera fini nous aurons une suite office qui est exécutable out-of-the-box après un make, sans la phase supplémentaire d'installation.

    Nettoyage du code

    Un énorme boulot a été fait là pour rendre le code-base plus facile à comprendre. Ça rend la lecture du code plus rapide et facile, permet de le vérifier, de comprendre le "flux" pour ajouter des fonctions et réparer des bugs.

     Des includes propres

    Dans les sombres vieux jours chaque module avait un répertoire inc/<module> intégré, où étaient cachés ses fichiers d'include externes. Pendant la compilation de chaque module, ces fichiers étaient copiés vers d'autres répertoires « artifacts » (le « solver ») et le module suivant était compilé à partir de ces copies. Ça posait plein de problèmes avec les débuggeurs qui identifiaient des copies des en-têtes, des débutants éditant les mauvais (solver) en-têtes, des problèmes de performance sous Windows, et plus. Donc merci à Bjoern Michaelsen, Matúš Kukan et Michael Stahl pour avoir migré tous les ent-êtes dans un dossier unique include à la racine, et nettoyer les makefiles pour rendre tout ça plus propre.

    Nettoyage des outils

    Le module tools/ était plein de fonctionnalités dupliquées et inutiles ; dans ce cycle nous avons retiré une abstraction complète du système de fichiers en la virant du code, grâce à Tomas Turek, Krisztian Pinter, Thomas Arnhold, Marcos Paulo de Souza & Andras Timar. Il est toujours bon pour la sécurité de retirer encore un énième code redondant et multi-plateforme de création temporaire sécurisée de fichier.

    Nettoyage des chaînes

    Nous avons continué à faire de bon progrès vers l'objectif consistant à retirer la classe obsolète UniString avec des retraits de méthodes effectuées par Jean-Noël Rouvignac & Caolán McNamara. De plus Lubos Lunak a procédé à une suppression de masse des préfixes des espaces de noms rtl:: pour le code de OUString et OString. Cela rend ce code plus lisible avec d'autres améliorations sur la propreté et les performances.
    Un grand nombre d'appels de fonctions ont été changés de UniString vers OUString, ont vu leur macro inutile RTL_USTRING_CONSTASCII retiré et utilisent maintenant des moyens plus rapides pour concaténer les chaînes.
    Merci à : Olivier Hallot, Christina Rossmanith, Stephan Bergmann, Chris Sherlock, Peter Foley, Marcos Paulo de Souza, José Guilherme Vanz, Jean-Noël Rouvignac, Markus Mohrhard, Ricardo Montania, Donizete Waterkemper, Sean Young, Thomas Arnhold, Rodolfo Ribeiro Gomes, Lionel Elie Mamane, Matteo Casalin, Janit Anjaria, Noel Grandin, Tomaž Vajngerl, Krisztian Pinter, Fridrich Strba (SUSE), Gergő Mocsi, Prashant, Ádám Csaba Király, Kohei Yoshida—et aux autres que j'ai raté dans les logs (envoyez moi un mail).

    Enregistrement des composants

    Noel Grandin continue sa quête indomptable pour nettoyer tous les appels créant des composants avec les nouveaux "service constructors", et toutes les améliorations qui vont avec. Cela représente environ deux cents cinquante commits dans cette 4.1

    Travail sur la qualité du code

    La moins visible des améliorations est peut-être celle qui retire des bugs provoquant des plantages. Il est clair que le but est de ne jamais planter, mais comment y arriver ? Markus Mohrhard a travaillé sur un ensemble de tests automatisés qui chargent plus de vingt-quatre mille fichiers différents —les plus vicieux et mal-formés que nous puissions trouver en écumant les tréfonds du bugzilla. Il y a eu un gros travail de Markus, Fridrich Strba (SUSE), Michael Stahl, Eike Rathke (Red Hat) pour corriger tous les bugs trouvés. Nous espérons que nos utilisateurs apprécierons de voir encore moins souvent la fenêtre moche signalant un crash.

    Une autre source significative d'améliorations est l'utilisation des techniques d'analyse statique pour améliorer la qualité du code, et donc sa fiabilité. Durant ce cycle une équipe a enquêté de façon systématique sur les données générées par l'outil coverity. Il en a résulté presque trois cents commits pour lesquels nous devons remercier Markus Mohrhard, Julien Nabet, Norbert Thiebaud, Caolán McNamara, Marc-André Laverdière (TCS), et bien d'autres.
    Il faut aussi ajouter les plus de soixante-cinq corrections de Julien Nabet et issues de l'outil intégré cppcheck. Enfin nous continuons d'utiliser Clang et les plugins très utiles de Lubos pour détecter et retirer le mauvais code dès qu'il apparait.

    Un autre outil qui s'est amélioré est bibisect puisqu'il permet d'avoir un dépôt git avec les binaires contenant les dernières dizaines de commits ayant été intégrés. C'est fort utile pour les utilisateurs/testeurs qui peuvent ainsi trouver très précisément à quel moment un bug a été introduit en bissectant de nombreux binaires dans le même dépôt git.
    Merci à Bjoern Michaelsen et au labo qualité de Canonical pour les serveurs de build.

    Nous avons aussi ajouté et vérifié de nouveaux tests unitaires dans LibreOffice 4.1, afin d'éviter les régressions dans le code. C'est assez difficles à mesurer parce que les gens aiment empiler de nouveaux tests dans les modules de tests unitaires qui existent déjà. En greppant sur la macro d'enregistrement CPPUNIT_TEST on peut constater l'ajout d'à peu près une centaine de tests dans la 4.1 —la majorité pour Calc mais aussi pour Writer, Chart2, la connectivité et Impress.
    Merci à Miklos Vajna (SUSE), Kohei Yoshida (SUSE), Noel Power (SUSE), Markus Mohrhard, Luboš Luňák, Stephan Bergmann, Michael Stahl, Noel Grandin, Eike Rathke, Julien Nabet, Caolán McNamara, Jan Holesovsky, Thomas Arnhold, Tor Lillqvist, David Ostrovsky, Pierre-Eric Pelloux-Prayer (Lanedo), Christina Rossmanith et les autres qui ont travaillé sur ces tests.

    Refonte du cœur de Calc

    Une des raisons pour lesquelles Calc a eu besoin de tests unitaires systématiques pour le code qui n'était pas couvert, c'est qu'un travail de re-factorisation profond est en cours au cœur du module. Depuis plusieurs années Calc est architecturé autour de l'illusion qu'un tableur est constitué de cellules - ce qui a créé de nombreux problèmes de performances et de passage à l'échelle. Le but final de ce travail de refonte est de se débarrasser définitivement de ScBaseCell et de passer à un stockage de données contiguës d'un type uniforme au niveau de la colonne. Les débuts de ce travail sont présents dans la 4.1 mais pour en percevoir les bénéfices il faudra attendre au moins jusqu'à la 4.2 ou même les versions suivantes où nous pourrons faire le travail d'ajustement pour utiliser au mieux cette nouvelle structure de stockage des cellules.

    Le but dans cette 4.1 est d'éviter toute régression visible en terme de performances, peut-être même de gagner un peu en terme de rapidité et de réduction de l'empreinte mémoire dans certaines zones. Mais le plus important c'est la meilleure maintenabilité du code du fait de la séparation entre le mécanisme d'utilisation des cellules et du système de stockage lui-même. Merci à Kohei Yoshida pour son excellent travail sur ce sujet.

    Traduction des commentaires en allemand

    C'est toujours encourageant de faire des statistiques à ce sujet. Dans ce cycle nous avons traduit en anglais près de cinq mille commentaires qui étaient en allemand. Cela aide les nouveaux développeurs à débuter sur le code, à le comprendre et à travailler plus rapidement. Le graphique (approximatif puisqu'il peut y avoir quelques faux positifs) ressemble à ça :

    Les lignes de commentaire en allemand qu'il reste à traduire

    Avec de nombreux remerciements à Urs Fässler, Christian M. Heller, Philipp Weissenbacher, Luc Castermans, David Verrier, Chris Sherlock, Joren De Cuyper, Thomas Arnhold, Philipp Riemer, et d'autres. De l'aide est attendue de la part des locuteurs allemands pour traduire les derniers seize mille commentaires. C'est juste une question de télécharger le code et de lancer bin/find-german-comments sur un module, de traduire quelques lignes et d'envoyer par mail un git diff à libreoffice At lists.freedesktop.org (pas besoin de s'inscrire).

    Portage Python des assistants

    Java demeure un environnement excellent, sans doute la solution privilégiée pour écrire des extensions multi-plateformes. Tout le support et les API de Java restent disponibles comme ils l'étaient avant. Ceci dit Java n'est pas disponible sur certaines plateformes et, en conséquence, l'utilisation de notre runtime Python interne peut se révéler judicieux pour construire de nouvelles fonctions.

    Cette version 4.1 apporte la conversion en Python des assistants précédemment en Java (qui sont accessibles sous Fichier -> Assistants). Cela devrait apporter des bénéfices tangibles aux utilisateurs Windows qui n'ont pas la chance d'avoir un JRE installé. Merci à Xisco Fauli et Javier Fernandez (Igalia).

    Édition des liens et démarrage

    Une des fonctions clés nécessaire pour faire tourner les prototypes LibreOffice sous Android et iOS est la possibilité de lier tout notre code au sein d'une unique bibliothèque partagée (Android) ou d'un unique exécutable (iOS). Ce travail est utilisable avec l'option de configuration --enable-mergelibs —qui agrège la majorité du code générique de LibreOffice au sein d'une seule bibliothèque partagée. Cela a été fait en collaboration avec Mozilla et c'est de plus en plus le choix par défaut des builds effectués par les distributions Linux puisque cela autorise des gains en terme de démarrage à froid. Du travail reste à réaliser en terme de réorganisation du code et de compilation guidée par des profils (PGO) afin d'améliorer encore plus les performances au démarrage.
    Merci à Matus Kukan (pour la Raspberry Pi Foundation) et à Tor Lillqvist pour leur travail.

    Une autre fonctionnalité liée aux performances qui a été financée par la Raspberry Pi foundation est la réduction des données de configuration qui sont analysées sans raison au moment du démarrage. Une des belles avancées dans ce domaine a consisté à retirer de la configuration plus de quatorze mille lignes de données d'impression d'étiquettes. L'analyse de ces lignes se fait maintenant quand quelqu'un a réellement besoin d'imprimer des étiquettes. Merci encore une fois à Matus Kukan pour ça.

    Nouveau format de type

    L'interface de programmation qui est utilisé dans LibreOffice a besoin d'une information sur le type, en particulier pour tout ce qui est scripting. Dans le passé cette information était stocké dans une base de données binaire au format vraiment antique et inefficace. Grâce à Stephan Bergmann (Red Hat) nous avons maintenant un tout nouveau format binaire plus efficace et compressé ce qui permet à notre offapi.rdb de passer de 6,5 Mo à 0,65 Mo. Plus de détails dans cette conférence FOSDEM. À l'heure actuelle ce format est seulement utilisé pour des informations internes et privées, nous prévoyons de rester complètement compatibles avec les extensions qui se basent sur l'ancien format.
    La documentation sur ce format est disponible dans l'arbre des sources. De nos jours nous avons de la documentation détaillée dans le fichier README de chaque module.

    Divers

    D'autres endroits du code où il y a eu des améliorations :

    Temps

    La résolution des types de données liés au temps dans UNO (l'API de LibreOffice) a été portée jusqu'à la nanoseconde alors qu'elle était auparavant limitée au centième et à la milliseconde. C'est surtout utile dans Base puisque LibreOffice ne tronquera plus les timestamps au centième de seconde ni les durées au millième pour les données utilisateur. Merci à Lionel Elie Mamane.

    Base

    Dans un formulaire, DatabaseListBox expose maintenant les valeurs sélectionnées (au lieu des chaînes qui sont affichées) à l'interface de scripting. Là encore des remerciements pour Lionel Elie Mamane.

    Migration de l'interface vers Glade XML

    La migration de l'interface vers des fichiers XML Glade a continué à un bon rythme avec des contributions de nombreux développeurs. Nous sommes passés de 64 descriptions de type .ui dans la version 4.0 à plus de 230 dans cette branche 4.1 (jusqu'à présent). C'est un progrès appréciable vers le but final des cinq cents fichiers.
    Merci à Caolán McNamara, Krisztian Pinter, Jack Leigh, Alia Almusaireae (KACST), Katarina 'Bubli' Behrens, Abdulaziz A Alayed (KACST), Jan Holesovsky, Faisal M. Al-Otaibi (KACST), Abdulmajeed Ahmed (KACST), Andras Timar, Manal Alhassoun (KACST), Bubli, Albert Thuswaldner, Olivier Hallot, Miklos Vajna, Abdulelah Alarifi (KACST), Gokul Swaminathan (KACST), Rene Engelhard, et d'autres. Il faut également mentionner l'excellent travail réalisé par les traducteurs pour vérifier et mettre à jour les chaînes de caractères.
    Le gain le plus important de cette migration de l'interface est qu'il est maintenant très facile de changer et améliorer l'interface utilisateur.

    Sorties de déboguage

    Il y a de nouvelles macro SAL_INFO et SAL_DEBUG qui facilitent l'ajout de sorties de deboguage filtrées ou temporaires. Nos crochets git vous préviennent aussi si vous laissez des déclaration de SAL_DEBUG au moment du commit.

    Construction des galeries

    LibreOffice a toujours été encombré avec un format assez hideux pour stocker les galeries. Nous mettons généralement à disposition les galeries d'images en tant que fichiers à part, mais nous avons aussi un ensemble de ressources binaires au sein même de LibreOffice et qui contiennent les miniatures de ces images ainsi que des nombres pour désigner les traductions des noms des images.
    Dans la 4.1 nous construisons la plupart des ces fichiers à la compilation pour chaque plateforme, ce qui les rend plus facile à compléter (et qui évite des binaires incompréhensibles dans git). Pour accompagner cela, nous traduisons les noms de thèmes avec une nouvelle syntaxe .desktop. Cela devrait faciliter la vie des utilisateurs voulant builder leurs propres galeries en tant qu'extensions et les mettre à disposition avec leurs traductions.

    Retrait complet de SDF

    Bien que nous ayons, dès la version 4.0, retiré SDF de la vue de nos contributeurs s'intéressant à la traduction, il restait des fichiers SDF qui étaient générés dans certaines étapes intermédiaires du build. Merci à Tamás Zolnai pour nous avoir permis de migrer vers une solution se basant purement sur des fichiers .po.

    S'impliquer

    J'espère que vous avez retiré de ce texte l'idée que les développeurs ont continué à se sentir chez eux au sein du projet LibreOffice et ont travaillé ensemble pour amener des améliorations significatives sous le capot…mais aussi sur la carosserie. C'était vraiment amusant de hacker avec eux sur certaines de ces nouveautés. Notre espoir est que, à mesure que le projet trouve son rythme de croisière, de nouveaux contributeurs vont nous rejoindre et découvrir à quel point c'est devenu fun et bien plus facile d'améliorer le code de nos jours. Vous serez en bonne compagnie, que ce soit en terme de contributeurs de code avec qui collaborer :

    Le nombre de contributeurs de code par mois

    Mais aussi en terme de diversité d'origine des commits. Nous aimons vraiment voir de nombreux contributeurs bénévoles sans affiliations, même si les quantités et les ratios varient en fonction de la saison, du cycle et du temps disponible pour la supervision :

    Le nombre de commits par mois et par affiliation

    Bien entendu nous maintenons une liste de tâches simples et courtes dans laquelle vous pouvez piocher afin de commencer à contribuer. Allez jeter un coup d'oeil sur notre page Easy Hacks et sur les instructions de build. Nous avons maintenant un environnement plus propre et plus sûr à partir duquel travailler à l'amélioration du code.

    Une des choses les plus simples à faire pour aider est de rapporter les bugs et de participer au tri de ces bugs (confirmer, corriger et améliorer les rapports de bugs des autres personnes). Avec seulement un peu d'expérience vous pouvez devenir un trieur efficace et les rapports de bugs bien rédigés aident vraiment les développeurs. Il vous suffit d'installer une pré-version et vous serez prêt à contribuer aux côtés des autres membre de l'équipe de développement. Encore mieux, vous pouvez participer au très fun concours de tri des bugs et gagner des prix.

     Conclusion

    LibreOffice 4.1 va être un nouveau jalon et nous espérons également qu'il fixera la barre en terme de qualité de code, d'améliorations du design et de fondations incrémentalement plus solides pour la meilleure suite bureautique du monde.
    Bien entendu, avec autant de changements, nous aimerions que vous testiez nos bêtas et nos version candidates, qui devraient (nous l'espérons) vous être utiles dans votre travail - pensez quand-même à sauvegarder régulièrement. Si vous n'avez pas le temps de tester nos bêtas et de nos version candidates, notre plan de sortie prédit une date pour la version finale à la fin du mois de juillet.

    Merci de soutenir LibreOffice.

    Lire les commentaires

  • La glace au blender (Journaux LinuxFR)

    En ces temps de chaleur estivale, une recette simple et efficace : la glace au blender (certains préféreront dire « mixeur », c’est plus français mais pas exactement la même chose).

    Il vous faut :
    - 3 minutes,
    - un bon blender (Philips HR2094 chez moi, mais n’importe lequel conviendra sûrement tant qu’il est capable de piler de la glace),
    - des fruits surgelés (framboises et mangue par exemple),
    - autant de lait que de fruits,
    - un peu de jus de fruit à votre convenance (jus d’orange par exemple),
    - ainsi que quelques épices (vanille, cannelle, etc. selon les goûts).

    Mettez tous les ingrédients dans le blender, 30 secondes en mode « glace pilée », puis une minute en mode « normal » pour homogénéiser. Vous obtenez une délicieuse glace maison à consommer immédiatement.

    Bon appétit !

    Lire les commentaires

  • SCO (Journaux LinuxFR)

    et un journal bookmark (mon premier ?), un !

    Ladies and Gentlemen, SCO v. IBM Is Officially Reopened ~pj

    Lire les commentaires

  • Agrégation et logiciels libres (Dépêches LinuxFR)

    L'agrégation de Mathématiques évolue doucement mais nettement. Pour la session 2015, seuls des logiciels libres seront proposés aux candidats au concours externe lors des épreuves orales. Le concours interne évolue lui aussi dans le même sens.
    Les deux concours se passent depuis plusieurs années sur ClefAgreg dans sa version 8.0, clef «live» fondée sur Debian, personnalisable et proposant différents logiciels libres dont bien sûr ceux non propriétaires utilisés à l'agrégation.

    NdM : voir aussi les dépêches précédentes en 2012, 2011, 2010, 2009, 2008 et 2007.

    L'utilisation de l'informatique aux concours de l'agrégation a démarré en 2002 pour le concours externe et 2009 pour le concours interne. Linux a été utilisé dès 2002 (avec Windows puis seul à partir de 2007). La distribution a été tout d'abord Mandrake puis Debian, le tout sous KDE puis fluxbox et enfin XFCE.

    Les logiciels qui seront utilisés à partir de 2015 seront Scilab, Octave, Sage, Maxima, Xcas et R. Cette liste est plus courte que la liste actuelle. Outre les logiciels propriétaires, Axiom, Gap et Pari/GP ne seront plus proposés.

    ClefAgreg est une clef USB bootable autonome fondée sur Debian. Directement téléchargeable sur le site, elle se compose d'une clef «de base» avec un système lançant XFCE et de toute une série d'extensions permettant d'installer une série de logiciels suivant la clef désirée. Elle se construit à partir d'un fichier ISO à l'image des clefs USB boutables usuelles. Formattée en VFAT, elle est utilisable normalement comme clef de stockage.

    La clef permet de construire ainsi

    • La clef dédiée à l'agrégation externe (version effective proposée aux candidats)
    • La clef dédiée à l'agrégation interne (version effective proposée aux candidats)
    • La clef dédiée à l'option ISN (qui a été distribuée aux enseignants concernés)
    • Une clef dédiée aux CPGE avec notamment un environnement python (Pyzo ou IEP) pour les besoins de l'enseignement informatique apparaissant à la rentrée 2013.

    Il s'y rajoute des extensions variées faites par des utilisateurs.

    Lire les commentaires

  • Affaire Diaspora*: Renouveau ? (Journaux LinuxFR)

    Salut nal,
    Je tenais à te partager ce lien en tant que journal bookmark comme personne ne l'a fait pour l'instant. Et aussi la contrepub de la part de DuckDuckGo.
    Comme quoi l'affaire PRISM ne profite pas qu'au mauvais côté de la Force.

    Voici une nimage (NSFW !)

    Sinon pour en revenir à Diaspora*, ils sont peut être à prendre encore avec des pincettes malgré un sérieux changement de staff.

    Lire les commentaires

  • Google+ Hangouts et Jabber/XMPP (Journaux LinuxFR)

    Cher journal, j’ai déjà révélé que bien que libriste (à mon petit niveau), mon ordinateur principal était un macbook . Je profite d’une nuit d’insomnie pour aggraver mon cas et préciser que je reste un grand admirateur de Google malgré tout ce qu’on peut leur reprocher (notamment, et au même titre que Apple, Amazon, … de payer beaucoup trop peu d’impôts). Je plaiderais ma défense en invoquant deux circonstances atténuantes : 1) on a tous nos petites contradictions, autant les assumer joyeusement 2) il est bon de s’inspirer de ce qui se fait de bon chez les autres (surtout si l’on ne considère pas que « copier c’est mal » ce qui est mon cas) et dans ce cas, ne faut-il pas pour le bien du libre qu’une partie d’entre nous penche du côté obscur de la force ?

    Je voudrais revenir et peut-être apporter un nouvel éclairage sur une nouvelle qui en tant que supporter de Google et du libre qui m’avait attristé il y a un mois : en rebaptisant son client jabber (qui avait beaucoup fait pour populariser xmpp, avoue le toi là moule qui déteste Google) en ce machin Google+ Hangout, Google ne portait-il pas un coup fatal à notre rêve de la fédération universelle de la messagerie instantanée ?

    Rapidement des commentateurs sur linuxfr avaient mis des bémols à cette nouvelle alarmiste. Non, XMPP n’était pas aussi bloqué et abandonné que ça et certains des indices qui allaient dans le sens contraire pouvaient aussi être expliqués légitimement (une manière expéditive de lutter contre le spam, en attendant mieux).

    Restait à expliquer pourquoi cet éloignement significatif tout de même entre XMPP et ce machin Hangouts. Personellement Hangout, mis à part la possibilité de démarrer une vidéo conférence à 10 personnes couplée à la bonne intégration dans l'agenda (deux avantages notables sur Skype), je m’y suis mis à contrecoeur. J’ai longtemps conservé l’ancienne interface Google Chat dans l’interface web de gmail, qui me semblait plus efficace que sa version soit-disant plus moderne dans plus.google.com, et je me suis abstenu de mettre à jour l’application Android.

    Puis au bout d’un mois Veni, Vidi, Vici comme disait l’autre. Je m’y suis mis, j’ai vu, j’ai compris. Alors au cas où certains seraient ici aussi durs de la comprenette que moi, voici mon explication.

    Hangout même si de manière extérieure et peut-être techniquement ça ressemble, ce n’est plus vraiment de la messagerie instantanée comme on y était habitués, c’est beaucoup plus proche d’un service comme WhatsApp.

    Je m’explique.

    Comme moi, cher journal, tu dois avoir une liste de contacts devenue avec le temps ingérable. Que met en avant un logiciel de messagerie instantanée classique ? La liste des gens en vert c’est à dire ceux qui sont connectés à un instant t. D’où deux conséquences pas forcément désirées :
    - on passe nettement plus de temps à communiquer avec les personnes qui sont le plus souvent connectées qu’avec celles qui ne sont connectées épisodiquement, indépendemment du fait qu’elles soient ou non importantes pour nous. A force de voir machin en vert, on se dit qu’il faudrait faire sa connaissance.
    - pour contrebalancer ça tout de même, parce que même si c’est sympa de rencontrer d’autres gens, il y a des personnes importantes dans notre vie qui ne sont connectées qu’épisodiquement, quand on voit que par hasard que ceux-ci le sont, on se précipite sur l’occasion, abandonnant la tâche qu’on était en train de faire. Pour les gens comme moi pour qui la procrastination et la résistance aux multiples distractions de l’ère moderne sont un problème, ça peut s’avérer gênant à la longue.

    Face à ces inconvénients, Hangout va mettre moins l’accent sur les communications instantanées que sur les communications souvent rapides certes mais asynchrones (peu importe qu’il réponde tout de suite, êtes vous vraiment à une demi-heure près ?) ; il va vous permettre de garder un focus non pas sur les gens qui sont le plus souvent connectés, mais sur ceux qui sont le plus importants pour vous. Humainement c’est un progrès si on pèse les choses objectivement.

    Je n’ai pas tout de suite compris celà.

    J’ai comme je l’ai dit longtemps préféré l’ancienne interface de Google Chat dans Gmail. Dans la nouvelle je ne comprenais pas où étaient mes interlocuteurs et comment je voyais s’ils étaient connectés ou pas (il y a une petite barre verte pour voir « s’ils peuvent répondre immédiatement » certes, mais on peut pas dire qu’elle soit mise en valeur). Dans ce nouveau paradigme, il faut faire l’effort de sélectionner mentalement les gens les plus importants pour vous. Vous leur adressez alors un petit message pour un prétexte quelconque et l’intérêt de la nouvelle interface se révèle alors à vos yeux : vous communiquez maintenant avec les bonnes personnes. Rajoutez à cela l’appli android qui va vous permettre par exemple de prendre rapidement une photo qui vous fait penser à quelqu’un et de lui envoyer avec un commentaire qui le fera marrer (sur l’ancien google chat, si je ne m’abuse, on ne pouvait pas insérer de photo). Mélangez le tout et vous aurez une raison valable et réaliste du revirement de Google par rapport à XMPP.

    Lire les commentaires

  • Un Concours pas complètement libre et même presque entièrement contraint... (Journaux LinuxFR)

    En ce samedi soir, si d'aventure vous vous ennuyez chez vous, et plutôt que d'aller voir des gens, des films ou la voûte céleste, pourquoi ne pas vous lancer dans un concours oujevipien?

    La clôture des inscriptions est fixée au 1er juillet, le jeu doit être terminé le 15 juillet.
    Ci-dessous le lien vers la page de l'organisation organisatrice avec toutes les contraintes:
    http://vdmlab.fr/?p=202
    Et là le thème du concours (plus d'autres jeux potentiellement amusants):
    http://oujevipo.fr/

    À voir si la vie est plus belle sous contrainte ou sous-contrainte…

    PS: ce journal prête son flanc à la critique aux limites du masochisme… il est question de .exe quelque part. Je compte sur votre indulgence.

    Lire les commentaires

  • Assemblée Générale de l'association GULL StarinuX (Dépêches LinuxFR)

    Le GULL StarinuX tiendra son Assemblée Générale Ordinaire annuelle

    Le samedi 29 Juin à 14h30, salle AGECA, 177 rue de Charonne 75011 Paris
    (métro Alexandre Dumas)

    Toutes les personnes intéressées par le Logiciel Libre et OpenSource sont invitées à y participer et sont les bienvenues.

    C'est le moment de rencontrer la communauté StarinuX, passionnée par l'informatique Libre !

    Venez découvrir nos actions, proposez vos idées et vos compétences.

    Seuls les membres actifs peuvent voter.

    Lire les commentaires

  • Comment créer une carte Open Street Map (Dépêches LinuxFR)

    Vous avez déjà essayé de créer une carte personnalisée sur votre site ? Ce n’est pas toujours une partie de plaisir… Certains fournisseurs de map proposent des cartes très esthétiques, mais peu personnalisables, d’autres sont lourds à implémenter, bref, construire une carte à base d’open data peut être un parcours du combattant.

    Mapping : why U no easy ?

    Ce guide ne cherche pas à être exhaustif, il s’agit surtout d’un partage d’expérience, fort limité du fait que je ne suis pas un développeur ou mappeur professionnel. En revanche, je pense bien représenter le public non-codeur qui souhaiterait passer ces obstacles, et si cet article peut aider un débutant comme moi à trouver des ressources, des idées et des bouts de code pour parvenir à réaliser son objectif, alors cet article aura joué son rôle.
    N’hésitez pas à partager vos avis, critiques et conseils dans les commentaires !
    On commencera par lister quelques exemples de cartes, on verra un ou deux exemples de plateformes de création de carte sans coder, puis on entrera dans les détails du code nécessaire pour monter une carte avec OpenLayers.

      Sommaire

      I. Exemples de cartes

      Commençons par voir quelques exemples de projets de carte basés sur OpenStreetMap :

      • opencyclemap.org est une carte des pistes cyclables.

      • openpistemap.org est une carte des pistes de ski.

      • openptmap.org trains, métros, tramways et bus.

      • öpnvkarte.de aéroports, métros, tramways et bus.

      • wheelmap.org accessibilité aux fauteuils roulant.

      • maposmatic.org génération de cartes de villes. Attention, générer la carte d’une grande ville prend beaucoup de temps à la création et à la lecture ! L’export est possible au format pdf, png, svgz et csv. Pour une grande ville, le format png est recommandé. Le format csv liste les noms de rues et de bâtiments publics avec leurs positions sur la carte (pas de coordonnées gps, juste des positions dans la grille générée dans les autres formats).

      • leretourdelautruche.com/map/nuke/ carte des centrales nucléaires dans le monde, avec sites d’explosions nucléaires.

      • gotronic.fr/carte-des-fablabs.htm une carte des FabLabs en France et dans le monde. Disclaimer : j’en suis l'auteur. C’est ma première map donc elle pourrait très certainement être améliorée.

      Une liste de cartes beaucoup plus exhaustive est disponible sur le wiki d’openstreetmap

      II. Construire une carte sans coder

      Si vous souhaitez construire une carte utilisant des données issues d’Open Street Map, mais ne souhaitez pas coder, au moins deux solutions sont disponibles.

      • Umap. Il est possible de dessiner des zones, placer des marqueurs, des lignes, définir le niveau de zoom et le centrage, choisir un fond de carte, le tout en quelques clics.

      Umap

      On peut importer des données au format GeoJSON, KML, GPX et CSV. Voir section « couches de données ».

      Une fois la carte terminée on peut extraire le code html, une URL (compressée) de la carte, ou télécharger les données au format GeoJSON.

      Remarque : il est possible de choisir la licence WTFPL, dont l’acronyme signifie « do What The Fuck you want to Public Licence » !

      Il va sans dire que ces cartes sont donc sous licence publique.

      • Open Mapquest.
        Un peu limité en fonctionnalités, on ne peut qu’afficher des points d’intérêt parmi une liste proposée ou tracer des itinéraires. J’ignore s’il est possible de personnaliser l’import/export de données. Il en existe probablement d’autres que je n’ai pas cité, n’hésitez pas à me le signaler dans les commentaires !

      III. Coder une carte

      Coder une carte requiert deux choses :
      Des tuiles et une bibliothèque javascript. Les tuiles forment la base de la carte, et des couches (layers) sont ajoutées par-dessus pour afficher des points, des reliefs, zones, popups, etc. par-dessus les couches utilisées.

      Représentation simplifiée des couches d’une carte.

      1. Les tuiles

      Ce sont les blocs qui constitueront la carte. Ces blocs sont chargés en fonction de la zone de la carte affichée.
      Voici une liste de quelques serveurs de tuiles avec des exemples de leur rendu.

      Typiquement, ce sont les tuiles Mapnik qui sont utilisées par OSM, CloudMade, MapQuest et MapBox, elles ressemblent à cela :

      Titre de l'image

      2. Une bibliothèque JavaScript

      C’est un ensemble de fonctions JavaScript prédéfinies pour exploiter les tuiles et les couches qui se superposeront dessus.

      • Leaflet
        Bibliothèque open source. Un exemple simple de création de carte est détaillé pas à pas dans ce guide (en anglais). Voici le résultat.
        Cet exemple utilise les tuiles cloudmade (donc le rendu Mapnik) et reste relativement basique (pas de récupération de données d’OSM).

      • OpenLayers
        Open source. On peut trouver quelques exemples sur cette page. C’est un peu difficile de s’y retrouver sur leur site, à l’image de cette bibliothèque qui est un peu plus difficile à exploiter que leaflet. OpenLayers semble être la bibliothèque la plus complète toutefois.

      • MapQuest

      • MapQuery (http://mapquery.org/) combine OpenLayers et jQuery.

      • Cloudmade

      • Via Michelin

      • Yahoo Map

      • Microsoft Virtual Earth

      • Google Maps

      • etc.

      Comparaison du code nécessaire pour créer une carte avec différentes bibliothèques sur trippingthebits.com. Sont testés Bing, ESRI, Google, MapQuest, OpenLayers, OVI et Leaflet.

      Voici un résumé des liens entre plusieurs fournisseurs de cartographie Web gratuite, comprenant des bibliothèques javascript mais aussi des applications ou plateformes. Image issue de cet article.

      Titre de l'image

      3. Des couches de données (optionnelles)

      Pouvoir coder une carte est bien, mais l’intérêt est surtout de pouvoir ajouter des POI ou points d’intérêts justement.

      a) Première possibilité : utiliser des données fixes

      Une méthode est d’aller sur http://overpass-turbo.eu/ (par exemple) et de coller ce bout de code avant de cliquer sur « run » :

      <query type="node">
  <has-kv k="LA-CLEF" v="SA-VALEUR"/>
</query>
<print/>

      En remplaçant les caractères en majuscule. Par exemple pour retrouver tous les nœuds dont le tag « nom » a pour valeur (exacte) « Charles de Gaulle », cela donnera

      <query type="node">
  <has-kv k="name" v="Charles de Gaulle"/>
</query>
<print/>

      Il est aussi possible d’utiliser du regex, par exemple pour trouver tous les nœuds comprenant les termes « Charles de Gaulle » :

      <query type="node">
  <has-kv k="name" regv="Charles de Gaulle"/>
</query>
<print/>

      Dans ce cas on trouvera alors 107 résultats au lieu de 38 seulement avec la valeur exacte :

      Titre de l'image

      Plus de détails sur l’utilisation d’overpass turbo ici.
      On peut exporter ces données en cliquant sur « export » et en choisissant son format.
      Ce fichier peut donc être conservé sur le serveur du site sur lequel la carte est codé et ses données seront définitives donc ne prendront pas en compte d’éventuelles modifications apportées sur OpenStreetMap.

      Une autre façon de récupérer ce fichier est d’utiliser une URL contenant les commandes destinées à l’API. Dans notre cas la commande serait  ?data=node["name"="Charles de Gaulle"];out+meta;
      Et l’url (avec l’encodage des espaces) http://overpass-api.de/api/interpreter?data=node["name"="Charles%20de%20Gaulle"];out+meta;

      Ensuite pour exploiter ces données avec OpenLayers, il faut créer une layer exploitant le fichier de données stocké sur le serveur. Par exemple, s’il s’agit d’un fichier osm, cela donnera :

      var layer = new OpenLayers.Layer.Vector("POIs", {
    projection: map.displayProjection,
    strategies: [new OpenLayers.Strategy.Fixed()],
    protocol: new OpenLayers.Protocol.HTTP({
                url: "data.osm",
                format: new OpenLayers.Format.OSM()
      })
    });
map.addLayers([layerMapnik, layer]);

      Remarque importante : le fichier data.osm doit se trouver sur le même serveur que la page.
      Pour utiliser un autre format de fichier, comme un .txt par exemple, il faudra adapter le protocole :

      protocol: new OpenLayers.Protocol.HTTP({
          url: "data.txt",
          format: new OpenLayers.Format.Text()
})

      On peut trouver la liste des formats supportés sur cette page (dans le menu de gauche)

      b) Deuxième possibilité : Données « live »

      Afin d’afficher sur sa carte des informations directement extraites d’Open Street Map et toujours à jour, il faut passer par une API, et faire traiter le fichier récupéré directement par l’interpréteur javascript.
      Avec OpenLayers, il suffit d’utiliser la variable var data_url
      Cela donne par exemple :

      <script type="text/javascript">
      var lat = 50.727;
      var lon = 7.092;
      var zoom = 15;
      var data_url = "api/interpreter?data=node["name"="Charles%20de%20Gaulle"];out+meta;";
      var zoom_data_limit = 13;
      var map;

      Pour plusieurs couches de données, il faut plutôt utiliser la fonction make_layer()

      map.addLayers([
    make_layer("http://overpass-api.de/api/interpreter?data=node["name"="Charles%20de%20Gaulle"];out+meta;", "blue"),
    make_layer("http://overpass-api.de/api/interpreter?data=node["name"="Charles"];out+meta;", "red"),
    ]);

      4. Des popups ou évènements (optionnels)

      Il est possible d’afficher des fenêtres lorsqu’un utilisateur clique sur un marker de la carte. En revanche, je n’ai pas trouvé comment le faire sur des données live, mais seulement en exploitant un fichier de données. Si vous savez comment faire ça, décrivez la procédure dans les commentaires et je l’ajouterai à l’article.
      Il faut pour cela trois fonctions. Une fonction de création de la popup, une décrivant les informations à présenter dans la fenêtre, et une dernière pour fermer la fenêtre :

      function onPopupClose(evt) {
    selectControl.unselectAll();
    var feature = this.feature;
    if (feature.layer) {
        selectControl.unselect(feature);
    } 
    else {
        this.destroy();
    }
}
function onFeatureSelect(event) {
    var feature = event.feature;
    var content=    
    "<h2>"+feature.attributes.name + "</h2>" 
    + feature.attributes.addrfull + "</br>";
    popup = new OpenLayers.Popup.FramedCloud("featurePopup",
        feature.geometry.getBounds().getCenterLonLat(),
        new OpenLayers.Size(100,100),
        content,
        null, true, onPopupClose);
        feature.popup = popup;
    map.addPopup(popup);
}
function onFeatureUnselect(event) {
    var feature = event.feature;
    if (feature.popup) {
        map.removePopup(feature.popup);
        feature.popup.destroy();
        delete feature.popup;
    }
}

      Ici on suppose que les données possèdent les attributs name et addrfull.
      Remarques :

      • Il semblerait que les « : » posent problème aux fonctions javascript. Il m’a donc fallu les supprimer dans le fichier .osm et remplacer les « addr:full » par « addrfull ». Il existe surement d’autres façons de contourner ce problème.

      • Si la liste des attributs à afficher dans la popup s’allonge, attention de vérifier qu’ils soient tous présents dans le fichier ! Sinon cela affichera un magnifique « undefined » dans la popup…

      Une façon de contourner le problème est de tester la présence des attributs avant de les utiliser. Par exemple :

      if (feature.attributes.addrfull === undefined) {
    var content=                                
        "<h2>"+feature.attributes.name + "</h2>";
} else {
    var content=    
         "<h2>"+feature.attributes.name + "</h2>" 
         + feature.attributes.addrfull + "</br>";
}

      IV. A vous de jouer !

      Voilà, les possibilités pour créer une carte à base d'OpenStreetMap sans coder existent, même si elles restent limitées à mon avis (prouvez moi le contraire dans les commentaires ;-). Pour ce qui est de l'utilisation d'OpenLayers (ou Leaflet), c'est certainement d'un niveau assez facile pour un développeur chevronné, et il est possible d'aller beaucoup plus loin que ce qui est décrit dans cet article.

      Lire les commentaires

    • Music Player Daemon (Dépêches LinuxFR)

      La mise en place d'un nouveau site web pour le projet MPD est l'occasion de revenir sur ce lecteur audio.

      MPD

      Sommaire

      « Music Player Daemon » est un lecteur audio écrit en C et basé sur une architecture client/serveur. MPD peut lire la plupart des formats audio pour peu qu'il soit compilé avec la prise en charge de ces derniers. Il permet de diffuser sur la carte son de l'hôte, de relayer le flux audio à un serveur dédié comme icecast, ou encore de diffuser lui-même un flux audio en http.

      Les fonctionnalités de pur lecteur audio de MPD sont classiques, ce qui fait sa spécificité et son intérêt est son architecture client/serveur. De fait, MPD en lui-même n'assure que la partie serveur, c'est-à-dire la lecture de la musique et la construction d'une base de données à partir de votre médiathèque. L'accès à MPD se fait via le réseau et un protocole dédié. De nombreuses applications clientes gravitent donc autour du lecteur pour satisfaire à tous les besoins : frontal graphique pour l’environnement de bureau, client pour la console, la ligne de commande, mobile, web, etc.

      Des bibliothèques de développement sont disponibles dans la plupart des langages populaires, C/C++ bien sûr, mais aussi Java, Perl, Python, Ruby ou Php. Hormis la bibliothèque C/C++ maintenue par le projet MPD, les autres sont issues de la communauté.

      Architecture client/serveur

      Les intérêts de l'architecture client/serveur par rapport au lecteur classique sont multiples ; la pertinence de chacun est bien évidemment fonction des habitudes et modes d'écoute de la musique :

      • Démon : Indépendance vis-à-vis du frontal, du client et même de l'utilisateur. Par exemple le lecteur n'est pas attaché à un serveur X : il peut être piloté par différents utilisateurs en même temps ;
      • Multi-client : il est possible d'écrire des clients qui ne font qu'une chose et le font bien™, du simple client en ligne de commande (mpc) pour lancer un réveil planifié le matin à l'application graphique (gmpc) permettant d'explorer finement votre médiathèque, ou encore un utilitaire qui enregistre l'activité de vos écoutes dans un fichier, sur votre (µ?)blogue, sur jabber ou encore last.fm ;
      • Réseau : Pilotage du lecteur à travers le réseau, sur votre LAN domestique (votre smartphone comme télécommande améliorée) ou à travers l'internet. Ce point est particulièrement intéressant quand on demande à MPD de jouer un flux audio en http plutôt (ou en même temps) que sur la carte son. Cela permet alors d'avoir sa propre radio web et de la piloter à distance ; une alternative aux Last.fm, Deezer et autre nuageux Itune.

      Quelques clients

      Une liste non exhaustive mais relativement bien fournie est disponible. Ci dessous quelques clients remarquables :

      Ligne de commande

      Mpc est le client en ligne de commande livré avec mpd. Des commandes comme mpc pause, mpc shuffle, etc., permettent de contrôler la lecture. La commande mpc update doit être lancée pour que les nouveaux fichiers musicaux du répertoire de musique soient accessibles aux clients pour la création de listes de lecture.

      Clients graphiques

      • gmpc : un frontal GTK2 très complet avec gestion des pochettes, affichage de diverses meta-informations (Wikipédia, paroles, artistes similaires…). Bien que le g de l'acronyme signifie Gnome ce n'est pas un projet du gestionnaire de bureau ;
      • xfmpc : un frontal GTK2 sommaire, mais très léger, pour le bureau Xfce ;
      • sonata : un frontal GTK2 écrit en python. Le projet est mort (la dernière version stable 1.6.2.1 date de septembre 2009) mais différentes branches existent, dont celle de multani qui semble être la plus maintenue, avec un portage en GTK3. Elle gère les pochettes locales ou distantes, la récupération des paroles ou encore le scrobbling ;
      • ncmpc : un frontal pour la console écrit en ncurse. Minimal mais complet, ce client est idéal pour parcourir sa médiathèque en console. Une alternative offrant plus de fonctionnalités est ncmpcpp, avec, en particulier, l'édition des méta-données ( tags ) ;
      • Ario : un frontal multiplateforme en GTK2 inspiré par Rhythmbox. Captures d'écran ;
      • Cantata : un frontal très complet écrit en Qt4 ;
      • gkrellmpc : un greffon de GKrellm pour contrôler la liste de lecture ;
      • mpdule : un module Enlightenment pour afficher le titre de la chanson et contrôler la lecture.

      Clients utilitaires

      • mpdris : client apportant la prise en charge de MPRIS V2.1 ;
      • mpdc : un gestionnaire de liste de lectures présenté sur Linuxfr ;
      • MPD_sima : un démon permettant l'ajout automatique de titres similaire à la lecture courante ;
      • mpdscribble : un client de partage de préférences musicales pour Last.fm, Libre.fm ou vers un simple fichier texte.

      Client Web

      Clients Android

      • MPDroid : Fork de PMix, il est compatible ICS (4.0) et gère la lecture sur la sortie HTTP de MPD sur le port par défaut (8000) ;
      • Droid MPD Client : Client plus maintenu depuis 2011, assez bogué.
      • PMix : Le client historique. Plus maintenu depuis 2010 ;

      Nouveautés

      • Protocole : ajout du « client to client » au protocole permet au client d'ouvrir des canaux de communication entre clients ; Une application possible est l'écriture d'un démon qui partagerait les meta-données aux autres clients — typiquement des images (pochettes d'albums ou autres), les paroles de chansons, etc. Cela permet, via un client unique, de mutualiser des fonctionnalités.
      • format : la gestion des cue sheet ;
      • extensions : des extensions pour les services en ligne Last.fm et Soundcloud ;
      • portage : le travail a débuté sur la branche 0.15, désormais MPD tourne aussi sous Windows ;
      • fonctionnalité de proxy : expérimentale pour le moment, elle permet de partager une base de données entre instances de MPD. Cela permet par exemple d'avoir un MPD maître sur le NAS qui héberge votre musique, de construire la base sur celui-ci et de distribuer cette dernière sur vos instances clientes. La base est ainsi construite et mise à jour une seule fois avec un accès disque direct plutôt qu'au travers un partage de fichiers sur le réseau.

      La version 0.17 est disponible dans Debian, Archlinux et bien d'autres distributions, mais aussi sur Windows ou sur OSX (via Macports ou Homebrew).

      Lire les commentaires

    Les mathématiques ont des inventions très subtiles et qui peuvent
    beaucoup servir, tant à contenter les curieux qu'à faciliter tous les
    arts et à diminuer le travail des hommes.
    -+- René Descartes -+-