Linux (fr)

  • De la différence entre PAM et NSS (Laboratoire Linux SUPINFO)

    De la différence entre PAM et NSS

     

    Note: ce document est le dernier d'un cycle de trois articles sur l'authentification sur les systèmes Linux. Les premier se trouvant ici et le deuxième .

    Lorsque l'on aborde l'authentification sous Linux, on est vite confronté aux deux mécanismes que sont PAM et NSS. Et à ce moment là une question peut venir à l'esprit : Quelle est la différence entre PAM et NSS qui permette de choisir l'une ou l'autre de ces solutions ?
    C'est donc à cette question que je vais essayer de répondre ici.

     

    Il est vrai qu'au premier abord ces mécanismes semblent faire la même chose, à savoir pouvoir s'authentifier sur un système Linux en utilisant différents services (fichiers plats locaux, serveur LDAP, serveur Active Directory, etc).

    Mais en regardant de plus près, on peut s'apercevoir qu'ils n'ont qu'une petite partie commune.
    En effet, il suffit simplement de s'intéresser à leurs noms pour comprendre leur fonction réelle.
    Pour PAM, Pluggable Authentification Modules, on se rend bien compte que son rôle est l'authentification des utilisateurs. Par contre, pour NSS, Name Service Switch, c'est une autre histoire. NSS est, comme son nom l'indique, une série d'interrupteurs pour choisir les services de données du système. Ces données peuvent être les utilisateurs, et dans ce cas là cela peut rentrer en compte pour l'authentification, mais ils peuvent être aussi beaucoup d'autres choses comme des noms de domaines, des listes d'alias d'adresses email, des correspondances entres des numéros de port et des services, etc. Le rôle de NSS est en fait de gérer les sources qui alimenteront la liste de ces types de données.

    Afin de mieux comprendre à quel moment PAM et NSS peuvent se chevaucher, il suffit de s'intéresser à l'évolution de l'authentification sur les systèmes Linux.

    À l'origine, les applications authentifiaient l'utilisateur en faisant appel aux bibliothèques du système. Ces dernières allaient alors regarder dans les fichiers /etc/passwd et /etc/shadow afin de vérifier l'existence de l'utilisateur et la conformité du mot de passe entré.
    On peut schématiser ce processus ainsi :

    Schéma du processus d'authentification basique sous Linux

    Ensuite, avec l'arrivée de NSS, on a pu élargir le nombre de sources pour les données du système. Concrètement, au lieu d'aller chercher les données seulement dans les fichiers plats, les bibliothèques système ont pu utiliser d'autres sources comme un serveur LDAP, une base de données SQL, un serveur Active Directory, etc. Mais ce sont toujours ces bibliothèques qui gardent le rôle d'authentifier l'utilisateur et donc cette authentification se fait sur le système local.
    Cela a au final changé notre précédent schéma ainsi :

    Schéma du processus d'authentification sous Linux avec NSS

    Enfin, lorsque les distributions Linux ont implémenté PAM, l'authentification n'a plus forcément été faite par les bibliothèques du système. C'est PAM qui à ce moment là choisit comment se fait l'authentification, suivant les modules qui sont activés. Si le module est pam_unix.so, l'authentification sera toujours gérée par les bibliothèques système en fonction des données fournies par NSS. Au contraire, si le module est pam_ldap.so ou pam_krb5.so, l'authentification se fera via un serveur LDAP ou Kerberos. C'est à dire que dans ce dernier cas, c'est au serveur externe que sera déléguée la vérification du jeton (ou mot de passe) et non plus sur le système local.
    En reprenant notre schéma, on arrive à ce résultat :

    Schéma du processus d'authentification sous Linux avec PAM et NSS

    On se rend maintenant compte pourquoi on peut avoir l'impression que PAM et NSS se chevauchent dans leur rôle.

    Les principales différences que l'on peut noter entre ces deux mécanismes sont donc les suivantes :

    • Avec NSS l'authentification est gérée par le système local, alors qu'avec PAM elle est délégué à un serveur externe (lorsque le module choisit n'est pas pam_unix.so). L'avantage qui en découle pour PAM est que le mécanisme d'authentification sera le même sur toutes les machines du réseau.
      Au contraire, cela pouvait poser problème avec NSS car chaque machine vérifiait le mot de passe suivant son propre mécanisme. En effet, si les machines d'un parc utilisent NSS et qu'une de celles-ci créé un utilisateur avec un mot de passe chiffré en MD5 qui est ensuite stocké dans un serveur LDAP, l'utilisateur ne pourra pas se connecter sur un machine chiffrant ses mots de passe en SHA-2 car la vérification sera fausse.
    • PAM est réellement dédié à l'authentification contrairement à NSS qui lui gère les sources qui alimenteront une liste de données. PAM permet donc d'effectuer diverses actions en plus de la simple vérification du jeton. Il peut par exemple limiter l'accès de l'utilisateur à certains horaires ou certains moyens (console, interface graphique) ou empêcher l'authentification après un certain nombre d'échecs.
      C'est aussi parce qu'il est dédié à l'authentification que PAM peut authentifier un utilisateur via Kerberos contrairement à NSS. En effet Kerberos utilise des jetons, ce qui ne sert à rien à NSS pour alimenter les listes de données qu'il a à gérer.

    Pour conclure, le choix entre PAM et NSS est une question qui a déjà été évoquée sur le Web, mais sans obtenir de réponse précise et développée. J'espère donc avoir pu éclairer les utilisateurs qui se retrouvent un jour confrontés au système d'authentification de Linux.

     

    Ressource supplémentaire :

     

  • Un nouvel outil pour synchroniser Postgres et LDAP (Journaux LinuxFR)

    Salut les moules,

    Comme je sais qu'il y a quelques DBA parmi nous, je passe la nouvelle: j'ai travaillé depuis un mois sur un outils pour créer les rôles dans Postgres à partir d'un annuaire LDAP: ldap2pg.

    Pour la petite histoire, contrairement à PAM, PostgreSQL a besoin que les rôles soient créés dans l'instance avant de demander à LDAP d'authentifier l'utilisateur. Dis autrement, LDAP ne sert qu'à récupérer le mot de passe, c'est toujours PostgreSQL qui stocke les rôles, leurs options (SUPERUSER, LOGIN, etc.) et l'héritage de rôles entre eux.

    Il y a un projet pg-ldap-sync qui existait déjà. Pourquoi avoir réinventé la roue ? D'abord un soucis pratique: c'est en ruby, et on installe rarement ruby sur un serveur PostgreSQL ou alors c'est pas la bonne version, très peu de dépendances sont disponibles en paquets rpm/deb. Ensuite, pg-ldap-sync est assez simple: une recherche LDAP pour les utilisateurs et une pour les groupes. L'idée de définir ça dans un fichier YAML propre est très chouette.

    Tous les utilisateurs ont les mêmes options: pas moyen de créer des SUPERUSER sans que tout le monde le soit. Je voulais gérer dans un seul fichier YAML la définitions des rôles d'une instance. Sinon il faut faire des blacklists pour ne pas dropper ce qu'on crée par ailleurs.

    En outre, je voulais aussi accorder ou révoquer les ACLs des rôles. Là ça commence à être assez avancé: je veux gérer qui a les accès DDL ou pas, les accès DML ou pas. Et sans que l'outil écrive les requêtes à ma place.

    Au final, en un mois de dév je trouve ldap2pg assez complet et pas mal documenté! Et vous comment gérez-vous les rôles de vos instances PostgreSQL ?

    Lire les commentaires

  • Le humble bundle Frozenbyte (Linux Certif)

    Le humble bundle est un pack de jeux indies vendu sans prix définit. Le principe est que l'acheteur choisit combien il est prêt à donner pour les jeux.

    Le système a quelques règles qui en font une offre particulièrement honnête par rapport à ce qui se fait habituellement en jeux vidéo:

    1. aucun DRM
    2. les jeux fonctionnent sur Linux, Mac OS X et même Windows
    3. vous payez ce que vous voulez

    Il y a déjà eu deux événement humble bundle, le troisième est actuellement en cours. Ce dernier s'appelle le "Humble Frozenbyte Bundle" car tout les jeux viennent de l'éditeur Finlandais Frozenbyte.

    Les jeux proposés sont:

    Le humble bundle est une très bonne opportunité de supporter les jeux indie et le jeux sur Linux. Pour le moment, les Linuxiens donnent 12$ en moyenne pour le pack, soit environ 8€.

    Si vous avez envie d'essayer ces jeux, il vous reste 10 jours pour participer.

  • Mise à jour des pages de manuel de Fedora (Linux Certif)

    Je suis motivé en ce moment :)

    Une fois de plus, j'ai mis à jour les pages de manuel, cette fois à partir des pages de la distribution Fedora.

    Depuis peu, mon ordinateur fonctionne grâce à Arch Linux, ce qui a posé pas mal de problème pour l'importation des pages. J'ai vérifié les pages manuellement et tout semble correct mais il est impossible d'être sûr lorsqu'on manipule autant de pages. N'hésitez pas à écrire si vous trouvez des problèmes.

    C'est 18545 pages de plus qui ont été ajouté au site (toutes langues confondues). Au total, le site héberge désormais plus de 200 000 pages! :)

    Il semble que Fedora ai réalisé un important effort de documentation. Beaucoup de nouvelle pages et de nouvelles traductions ont été introduite.

  • LinuxFr.org : première quinzaine de juin 2018 (Journaux LinuxFR)

    Nonante huitième épisode dans la communication entre les différents intervenants autour du site LinuxFr.org : l’idée est tenir tout le monde au courant de ce qui est fait par les rédacteurs, les admins, les modérateurs, les codeurs, les membres de l’association, etc.

    L’actu résumée ([*] signifie une modification du sujet du courriel) :

    Statistiques

    Du 1er au 15 juin 2018

    • 1528 commentaires publiés (dont 8 masqués depuis) ;
    • 248 tags posés ;
    • 80 comptes ouverts (dont 6 fermés depuis) ;
    • 35 entrées de forums publiées (dont 0 masquée depuis) ;
    • 20 liens publiés (dont 1 masqué depuis) ;
    • 21 dépêches publiées ;
    • 25 journaux publiés (dont 1 masqué depuis) ;
    • 3 entrées nouvelles, 1 corrigée dans le système de suivi ;
    • 1 sondage publié ;
    • 0 pages wiki publiées (dont 0 masquée depuis).

    Listes de diffusion (hors pourriel)

    Liste webmaster@ - [restreint]

    • R.A.S.

    Liste linuxfr-membres@ — [restreint]

    • [membres linuxfr] Bouffe des 20 ans le 28 juin à Paris

    Liste meta@ - [restreint]

    • [Meta] Incident du jour sur SSL/TLS
    • [Meta] Quel avenir pour la tribune ?

    Liste moderateurs@ - [restreint]

    • [Modérateurs] certificat linuxfr expiré
    • [Modérateurs] Incident du jour sur SSL/TLS
    • [Modérateurs] Certificat SSL
    • [Modérateurs] où se trouve les CSS de Linuxfr
    • [Modérateurs] forum - bug pour s'inscrire ?

    Liste prizes@ - [restreint]

    • [Prizes] LinuxFr prizes recap du samedi 9 juin 2018, 13:35:23 (UTC+0200)
    • [Prizes] J'ai gagné un livre!

    Liste redacteurs@ - [public]

    • [Rédacteurs] Incident du jour sur SSL/TLS

    Liste team@ - [restreint]

    • [team linuxfr] Certificat SSL du site linuxfr.org expiré
    • [team linuxfr] Tweet de Laurent Jouanneau (@ljouanneau)
    • [team linuxfr] Incident du jour sur SSL/TLS
    • [team linuxfr] Purge du compte X [*]
    • [team linuxfr] réouverture de compte
    • [team linuxfr] Organisez des événements dans le cadre de la Fête des Possibles, du 15 au 30 septembre 2018

    Liste webmaster@ — [restreint]

    • R.A.S.

    Canal IRC adminsys (résumé)

    • certificat X.509 périmé (encore merci à tous ceux qui l'ont signalé), passage à Let's Encrypt et communication post-incident
    • renouvellement du domaine (encore merci Yann)
    • dernière version de Jessie (8.11) prévu le 23 juin, et ensuite passage en fin de vie
    • question relative à la configuration DMARC de la liste Sympa des modérateurs qui change le From de l'émetteur dans certains cas
    • rachat de GitHub par Microsoft et dépôts LinuxFr.org. Faut-il bouger et pourquoi.
    • Let's Encrypt et HTTP en clair pour le renouvellement ? Voir par exemple la discussion
    • discussion sur les aspects sécurité de l'affichage distant d'images sur la tribune
    • « 20 ans le bel âge pour mourir », ah non ça parle de Yahoo Messenger, pas de nous
    • 20 ans du site et POSS en décembre ?
    • courriels envoyés pour préparer les entretiens des 20 ans
    • peu de présents aux RMLL dans l'équipe. Snif. Me laissez pas tout seul.
    • migration de alpha et main en Jessie
    • travaux en cours pour nettoyer le dépôt git d'admin (avec des fichiers générés par ansible notamment). Sans oublier de finaliser la partie Let's Encrypt…
    • toujours un conteneur à migrer en Jessie, et ensuite trois en Stretch. Et aussi un hôte Trusty à mettre à jour.

    Tribune de rédaction (résumé)

    • idée de dépêche : NetHammer (finalement parue sous forme de lien)
    • avis de grand calme

    Tribune de modération (résumé)

    • peu de présents aux RMLL dans l'équipe. Snif. Me laissez pas tout seul.
    • du spam
    • améliorations de CSS proposées par voxdemonix
    • les admins du site ont des facilités techniques pour traquer les spammeurs et les multis, par rapport aux modérateurs
    • retour des Geek Faeries

    Commits/pushs de code https://github.com/linuxfrorg/

    • (springcleaning) admin-linuxfr.org en cours de conversion vers Ansible
    • Allow users to choose the source for their tribune smileys in prefere…
    • Add a border for missing title on images
    • Fix max height for image on computer screen

    Divers

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • LinuxFr.org : seconde quinzaine de mai 2018 (Journaux LinuxFR)

    Nonante-septième épisode dans la communication entre les différents intervenants autour du site LinuxFr.org : l’idée est tenir tout le monde au courant de ce qui est fait par les rédacteurs, les admins, les modérateurs, les codeurs, les membres de l’association, etc.

    L’actu résumée ([*] signifie une modification du sujet du courriel) :

    Avertissement

    Ceci est un second message pour prévenir certains de nos visiteurs qui nous transmettent inutilement des infos sensibles via leur lecteur de flux RSS/Atom, infos qui se retrouvent stockées dans nos logs web.

    Format par défaut d'un log du serveur web Nginx (source) :

    log_format combined '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent"';
    

    Certains utilisateurs nous transmettent leur nom d'utilisateur distant (pas forcément gênant, mais inutile).

    Par contre, certains nous transmettent leur nom d'utilisateur ET leur mot de passe. On a ainsi leur nom d'utilisateur dans le champ remote_user mais aussi leur nom d'utilisateur et leur mot de passe en clair dans le champ http_referer, sous la forme http://login:pass@linuxfr.org/journaux.atom ou https://login:pass@linuxfr.org/news.atom. Cela concerne 6 utilisateurs différents (tous utilisateurs de FreshRSS), dont 1 a été identifié et contacté en privé. Pour les cinq autres, à savoir Jeoffrey, jm, lionel, SVNET et titoko, je vous suggère d'arrêter de nous envoyer votre mot de passe, puis de changer de mot de passe étant donné qu'il a fuité, et aussi d'utiliser préférentiellement la version HTTPS du flux souhaité. N'hésitez pas à me contacter en privé si vous avez des questions (oumph CHEZ linuxfr.org).

    La version FreshRSS 1.11.0 du 2018-06-03 corrige ce problème Strip HTTP credentials from HTTP Referer in SimplePie #1891.

    Statistiques

    Du 16 au 31 mai 2018

    • 1371 commentaires publiés (dont 11 masqués depuis) ;
    • 344 tags posés ;
    • 99 comptes ouverts (dont 9 fermés depuis) ;
    • 33 entrées de forums publiées (dont 1 masquée depuis) ;
    • 32 liens publiés (dont 1 masqué depuis) ;
    • 26 dépêches publiées ;
    • 30 journaux publiés (dont 1 masqué depuis) ;
    • 3 entrées nouvelles, 1 corrigée dans le système de suivi ;
    • 0 sondage publié ;
    • 2 pages wiki publiées (dont 1 masquée depuis).

    Listes de diffusion (hors pourriel)

    Liste webmaster@ - [restreint]

    • R.A.S.

    Liste linuxfr-membres@ — [restreint]

    • R.A.S.

    Liste meta@ - [restreint]

    • R.A.S.

    Liste moderateurs@ - [restreint]

    • [Modérateurs] Dépêche Refaire linuxfr
    • [Modérateurs] contenu problématique
    • [Modérateurs] nfsw
    • [Modérateurs] URL d'une dépêche

    Liste prizes@ - [restreint]

    • R.A.S.

    Liste redacteurs@ - [public]

    • R.A.S.

    Liste team@ - [restreint]

    • [team linuxfr] Optimize MySQL
    • [team linuxfr] Login/mot de passe envoyé en clair dans une URL HTTP sur LinuxFr.org
    • [team linuxfr] Login/mot de passe envoyé en clair dans une URL HTTP sur LinuxFr.org
    • [team linuxfr] Login/mot de passe envoyé en clair dans une URL HTTP sur LinuxFr.org
    • [team linuxfr] Test passage en Jessie
    • [team linuxfr] Joker.com: Your domains are about to expire (expiration report)

    Liste webmaster@ — [restreint]

    • R.A.S.

    Canal IRC adminsys (résumé)

    • mises à jour de sécurité
    • le support sécurité normal pour Debian GNU/Linux 8 Jessie s'arrête au 17 juin
    • expiration du certificat au 3 juin et discussion sur le renouvellement
    • deux conteneurs mis à jour en Jessie, en attendant le passage en Stretch
    • le conteneur de développement redirige tout le trafic en HTTPS désormais
    • une boucle de courriels entre un système de ticket et notre gestionnaire de liste de diffusion
    • travaux en cours pour nettoyer le dépôt git d'administration système (avec des fichiers générés par l'outil d'automatisation Ansible notamment)

    Tribune de rédaction (résumé)

    • Migration de GIMP vers GitLab ajoutée dans la dépêche sur la 2.10.2
    • Demande de retours sur la dépêche GrafX2 par le développeur principal
    • Une correction post-publication

    Tribune de modération (résumé)

    • du spam (dont un robot réutilisant des extraits de phrases)
    • modération d'une image déplacée
    • expiration de notre certificat X509 Gandi Wildcard au 3 juin
    • évocation du renouvellement du CNNum (on aurait pu mentionner les entrées au comité de prospective de la CNIL)
    • migration de deux conteneurs en Debian Jessie

    Commits/pushs de code https://github.com/linuxfrorg/

    • Merge pull request #222 from fredplante/master
    • Fix typo
    • (svgtex) fixes duplicate xlink attribute on svg result
    • (epub) Use https for LinuxFr.org URLs

    Divers

    • Geek Faëries du 1 au 3 juin : conférence « LinuxFr.org, 20 ans que ça geeke » et table ronde « Ces plates‐formes du Libre qui soutiennent les communautés » avec l'Agenda du Libre et En Vente Libre. Plein de mercis à Bookynette pour le Village du libre, à l'équipe organisatrice des GF, et à Marco et Marius pour l'hébergement.
    • Proposition de conférence soumise + table ronde + demande de stand pour les RMLL 2018 Strasbourg

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Compilation de VSCode sous Centos 6 (Journaux LinuxFR)

    Il y a quelques mois, le camarade freem< nous avait fait part de ses déception concernant VSCode parce qu'il ne trouvait pas matière à troller de manière satisfaisante.

    J'ai voulu me faire mon propre avis et l'essayer par moi même. Malheureusement, ma machine pro est une Centos 6 et la libc disponible beaucoup trop vielle. Impossible de l'essayer et donc de partager avec vous mes impressions pertinentes et de kalitay :(. Quelques moules m'ont gentiment expliqué que je n'avais qu'à me sortir les doigts du fondement et le compiler moi même, que si je voulais vraiment, je pouvais.

    Plusieurs mois plus tard, j'ai enfin trouvé le temps et la motivation d'essayer. Et à ma grande surprise, ce fut plutôt facile.

    # Installation d'une version décente de GCC, python et git depuis les dépots 
    # Softawre Collections
    sudo yum install centos-release-scl
    sudo yum install devtoolset-7 python27 rh-git29
    
    # Installation de NodeJS et Yarn
    curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -
    curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
    sudo yum install nodejs yarm
    
    # Activation de l'environnement de compilation
    scl enable python27 devtoolset-7 rh-git29 bash
    
    # Récupération des sources de VSCode
    git clone https://github.com/Microsoft/vscode.git
    cd vscode
    
    # Augmentation de la limite du nombre de fichiers ouverts à 166384
    # (il peut être nécessaire de modifier /etc/security/limits.conf pour atteindre
    # cette valeur)
    ulimit -n 166384
    
    # Récupération des dépendances
    # (On défini la variable CXX parce que sinon un des makefile utilise 
    # /usr/bin/g++ qui ne supporte pas C++11 )
    CXX=$(which g++) yarn
    
    # Construction du paquet
    yarn run gulp vscode-linux-x64-min
    
    # "Instalation"
    mv ../VSCode-linux-x64 ~/opt/vscode

    Et voilà ! À moi les joies des d'un éditeur moderne !

    $ ~/opt/vscode/bin/code-oss
    /home/killruana/opt/vscode/bin/../code-oss: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

    Lourd est le parpaing de la réalité sur la tartelette aux fraises de nos illusions. :'(

    Rendez-vous dans quelques mois pour la suite de mes aventures avec vscode.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Tutoriel : Comment utiliser la forge GitLab du labo pour gérer un projet ? (Laboratoire Linux SUPINFO)

    Initialiser un nouveau projet :

    1. Créer un compte sur la forge : http://code.labo-linux.org/users/sign_up
    2. Se connecter : http://code.labo-linux.org/users/sign_in
    3. Ajouter votre clé SSH : http://code.labo-linux.org/profile/keys
    4. Créer un nouveau projet : http://code.labo-linux.org/projects/new
    5. Suivre les instructions de lignes de commande GIT à exécuter pour initialiser le dépôt

    Le dossier ainsi créé va suivre les modification de tous vos fichiers. Vous devez maintenant apprendre à utiliser GIT en suivant dans l'ordre cette série de tutoriels : https://www.atlassian.com/fr/git/tutorial

    Si la ligne de commande vous rebute, il y a un client multiplateforme extrèmement complet : http://www.syntevo.com/smartgit/download (veillez à prendre la licence complète gratuite à usage non commercial).

    Pour que le versionnage soit utile, il faut Commit/Push à chaque fois que quelque chose est complété (comme un bug, une fonctionnalité, etc). Cela évite d'avoir des régressions et de pouvoir faire machine arrière le cas échéant.


    Découper son projet en toutes petites étapes :

    Cela permet d'y voir plus clair et de savoir par où commencer. Vous augmenterez votre motivation en évitant la paralysie de la feuille blanche.

    1. Se rendre sur l'interface Issues de votre projet (les liens sont à adapter) : http://code.labo-linux.org/root/demo/issues
    2. Cliquer sur New issue
    3. Décrire une tâche de l'ordre de « faire un hello world avec le framework X », « gérer le login/logout », « envoyer un email sur telle action », « créer une page de statistiques » ...
    4. Optionnellement, vous pouvez rattacher ces issues à des milestones (c'est un jalon, une version)


    Autres fonctionnalités utiles :

    1. Dans les champs texte, GitLab gère des symbols actifs comme le "@" (vous suggèrera les pseudos des membres) et le "#" (vous suggèrera vos issues).
    2. Préciser le numéro d'une issue dans un message de commit créé un référencement du commit dans l'issue. Exemple : le message de commit "Hello World #1" fera apparaitre un nouveau commentaire "mentionned in commit xxxxxx" dans l'issue n°1.
    3. Vous pouvez fermer automatiquement des issues dans vos messages de commit ! À découvrir en lisant ceci : https://about.gitlab.com/2013/09/22/gitlab-community-edition-6-dot-1-released/


    Git est un outil extrèmement puissant que vous découvrirez au fur et à mesure de vos besoins. Travailler en équipe requiers une réelle organisation en dehors de l'outil : répartition de tâches, tests préalables avant toute mise en commun pour limiter l'instabilité du logiciel, découpage en jalons, etc.

    Vous trouverez des réflexions sur les « workflows » (manière de s'organiser) sur cette page : https://www.atlassian.com/fr/git/workflows


    Gestion de projet plus globale

    La gestion d'issues proposée par GitLab ne peut pas se soustraire à une gestion d'équipe plus globale. Les Méthodes Agiles que vous découvrirez pendant votre cursus proposent de grands concepts qui évitent à de votre groupe de s'enrayer :

    1. Une réunion de départ qui dégage les jalons du projet, c'est à dire un premier découpage de ses grandes étapes qui n'entre pas dans le détail mais permet de fixer des échelles de temps
    2. Une revue hebdomadaire obligatoire, qui permet de définir à l'avance un objectif court terme pour l'équipe
    3. Un point journalier rapide, même s'il ne s'est rien passé, où chaque membre de l'équipe doit avouer ses difficultés et exprimer ce qui a été fait. Cela permet d'identifier au plus tôt qui a besoin d'aide.
    4. Une revue de projet (et une seule) toutes les deux semaines / un mois pour statuer sur l'avancée du jalon en cours ainsi que sur la prévision du prochain.

    Cette structuration de l'équipe par des cérémonies ponctuelles dans le temps neutralise l'effet « sous-marin » et permet à chaque membre de l'équipe de savoir où se situent les autres.

    L'objectif n°1 de ces méthodes est de faire passer le client et la qualité du logiciel avant toute chose. En itérant régulièrement, votre travail évoluera sur des bases saines car validerez au fur et à mesure qu'il correspond toujours aux attentes du client. La gestion des bugs devient ainsi prioritaire sur les fonctionnalités, si cela est pertinent. Ce fonctionnement est en totale opposition aux cahiers des charges dont le but est de figer un processus jusqu'à son aboutissement.

    Les Méthodes Agiles sont un genre de framework qui délimite bien d'autres routines d'équipe qui ne sont pas toujours adaptées à la situation : à vous de prendre ce qui vous plait ! C'est l'essence même de ces méthodes.

  • La Banque Postale bloque l'achat d'un VPN (Journaux LinuxFR)

    Bonjour,
    je vais vous raconter une partie de ma vie des fois que certaines personnes seraient dans la même situation.
    Une partie de mon argent se trouve à La Banque Postale. Je n'avais pas grand chose à lui reprocher jusqu'à présent.
    Il y a quelques semaines, je décide de souscrire un abonnement à ProtonVPN, un service VPN proposé par l'équipe derrière protonmail. Je m'apprête à souscrire à une offre payante, je saisis mes coordonnées bancaires et lorsque je valide, j'obtiens le message suivant

    Your card does not support this type of purchase. Please try a different card (Votre carte ne prend pas en charge ce type d'achat. Veuillez essayer une autre carte)

    Je réessaie mais toujours le même message. Je suis assez surpris car je n'ai jamais eu aucun problème de paiement avec ma carte bancaire alors que je l'utilise régulièrement pour payer des choses en ligne ou lors de voyage sur les 5 continents.

    Première étape

    Je contacte le service support de ProtonVPN pour leur expliquer mon problème. Après plusieurs échange, il semble bien que le problème vienne de ma banque.

    Deuxième étape

    Je contacte un « conseiller » de la banque postale pour résoudre ce problème. Trois jours après mon message, j'obtiens une réponse « bateau » qui m'informe que ma carte fonctionne parfaitement et je suis invité à contacter 3D SECURE pour plus d'information. Je réessaie donc de payer mon offre VPN mais j'obtiens le même message que précédemment.

    Troisième étape

    J'appelle 3D SECURE qui m'informe que ma carte fonctionne parfaitement et que le problème se situe au niveau de la Banque Postale. Je commence à ne pas aimer d'être mener en bateau. D'une part, le numéro de 3D SECURE est payant (je me demande bien pourquoi je paie des frais bancaires qui me permettent normalement de pouvoir payer avec une carte bancaire et autres joyeusetés ; ici ce service n'est pas rendu et je dois encore payer). D'autre part, le « conseiller » de la banque postale semble bel et bien être un « robot » fournissant des réponses toutes faites.

    Quatrième étape

    Je renvoie un message au « conseiller » de la banque postale un peu sec pour leur signaler que 3D SECURE m'a indiqué que le problème vient de chez eux. Trois jours plus tard, j'obtiens la réponse suivante

    Dans votre message ci-dessous, vous souhaitez obtenir des précisions concernant des refus de paiement en ligne.

    Nous avons transféré votre demande au service concerné qui vous répondra dans les meilleurs délais.

    Je réessaie alors d'acheter le service VPN et là, ça fonctionne normalement ; j'ai mon abonnement VPN. À noter que 10 jours après avoir reçu ce message, je n'ai toujours pas été contacté par le « service concerné ».

    Je ne sais pas s'il s'agit d'un hasard, mais ProtonVPN et ProtonMail étant liés, je ne peux pas m'empêcher de me rappeler le blocage par paypal des dons vers ProtonMail il y a 3 ans.

    En résumé, la Banque postale m'a énormément déçu. Si j'avais un compte twitter ou facebook, j'aurais contacté directement la banque pour leur demander des explications. Il parait que les entreprises n'aiment pas la mauvaise pub sur les réseaux sociaux et que ça aide à résoudre les « problèmes » rapidement. Mais comme je ne suis pas sur les réseaux sociaux, j'en parle ici pour qu'il y ait au moins un peu de pub sur ce sujet …

    Lire les commentaires

  • Opus 1.2 (Journaux LinuxFR)

    Journal bookmark pour annoncer la sortie d'Opus 1.2.

    Comme vous le savez sans doute Opus est un format ouvert permettant de faire de la compression audio avec pertes. Il s'adapte à un large éventail en fréquence et bitrate afin de couvrir à la fois les besoins de compression de la voix humaine (pour la VOIP) et de compression de la musique.

    Le boulot abattu dans cette version 1.2 à l'air remarquable et une page spéciale très bien foutue qui récapitule toutes les nouveautés est disponible sur le site de Xiph.org. Sur cette page vous pourrez tester des échantillons de voix et de musique à différent bitrate afin de constater les gains en qualité qu'apporte cette nouvelle version.
    Comme en plus Opus 1.2 est moins gourmand au codage et au décodage et a été fuzz-testé pour augmenter la sécurité, c'est la fête complète !

    Lire les commentaires

  • Publication de Pastèque version 7 (Dépêches LinuxFR)

    Plus d’un an et demi après sa version 6 annoncée sur LinuxFr.org, Pastèque sort en version 7. Malgré les aléas de la société éditrice, malgré les énergies consacrées à la loi de finance 2016, Pastèque vit encore. On détaille les nouveautés, qu’elles soient techniques ou communautaires.

    Pastèque

    Pastèque est une suite logicielle pour gérer un ou plusieurs points de vente (point of sales, POS). Avec le matériel adéquat (imprimante thermique, lecteur de cartes bleues…), elle permet de gérer tout point de vente : restaurant, épicerie, bar, librairie…

    Sommaire

    Nouveautés communautaires

    L’année a été mouvementée pour la société Scil, éditrice originelle de Pastèque, qui a fermé. Après des péripéties, il en sort une situation plus saine pour le logiciel qui se structure autour d’une association et de prestataires professionnels.

    L’association Pastèque

    Pour reprendre le développement du logiciel, plusieurs utilisateurs ont réaffirmé leur attachement à un outil libre et ont fondé une association. Citons ces humbles héros du quotidien, ceux qui font avancer la confidentielle et obscure cause des logiciels libres d’encaissement : Les mains dans le guidon, Robin des Bios, le Bis2Fly et Héricode.

    L’objet de l’association est le suivant :

    L’association a pour objet de créer, développer et assurer la promotion de l’informatique libre pour les commerçants. Ceci concerne aussi bien les logiciels libres que l’open hardware, les données ouvertes, la neutralité de l’Internet, le respect de la vie privée et de la confidentialité des données professionnelles, etc.

    Concrètement, elle va surtout coordonner le développement de Pastèque et attester le logiciel pour le rendre utilisable en France après le 1er janvier 2018 (conséquence de la loi de finances 2016). C’est un choix fort, par exemple, l’association Dolibarr semble renoncer à émettre des attestations ou à chercher la certification pour laisser ce bazar aux soins des intégrateurs.

    L’association se réunit chaque lundi à 19 h au Bis2Fly, 19 rue Nicolas Leblanc à Lille. Ne riez pas trop, on a déjà rencontré un dev’ venu de Marseille pour causer avec nous. On en a vu un autre, mais il venait de Bailleul, à 40 km. C’est moins impressionnant.

    Diversité des contributeurs

    L’association coordonne, mais elle ne détient pas les droits d’auteurs des contributions. Ça a une heureuse conséquence : le logiciel a de multiples auteurs et sa licence ne pourra pas être modifiée sans l’accord de tous les auteurs… Oh, wait!

    Le fait qu’une société ne soit plus centrale devrait permettre de passer à un écosystème plus sain, à la Dolibarr, par rapport à l’ancien écosystème moins sain, à la Odoo (ce troll est cadeau).

    Relations avec la communauté Dolibarr

    Un gros avantage des discussions autour de la loi de finances 2016, c’est que nous avons rencontré pas mal de développeurs importants de la communauté Dolibarr, au point que nous avons participé au devcamp Dolibarr qui s’est tenu au mois de mars dernier à Orléans.

    Ça nous a décidé à abandonner les fioritures de gestions. Pastèque va se concentrer sur son métier. On fait tourner des caisses enregistreuses ? Notre métier est donc d’encaisser et d’enregistrer.
    Pour le reste (statistiques, intégration à la comptabilité…), on va s’appuyer sur Dolibarr. On avait bien commencé un début de module pour Odoo il y a quelques années, mais l’humain ça compte beaucoup dans le développement des logiciels libres, non ?

    Nouveautés techniques

    La version 7 a surtout été la conséquence de grosses fusions Git des projets lancés dans l’année. Aucun n’était vraiment terminé. Nous avons tout examiné et validé uniquement ceux rapides à implémenter.

    Bureau

    Côté interface, rien de neuf. C’est sous le capot qu’on a touché : lancement plus rapide du logiciel, encaissement plus rapide et récupération des tickets perdus lors d’une perte de connexion Internet. Ça peut paraître peu, mais pour ceux qui utilisent le logiciel au quotidien, c’est énorme.

    Android

    Par où commencer ? Il y en a tant…

    On a une interface de vue des tables en mode restaurant, comme sur le bureau. On a un système de division des tickets simple et efficace, comme sur le bureau. Usage de gson pour se simplifier la vie. Beaucoup de nettoyage de code et de corrections de bogues. Ça va plus vite, ça crashe moins souvent.

    La vue en table et la division de ticket rendent pasteque-android enfin utilisable dans les bars et restaurants.

    Serveur

    On fait évoluer l’interface (usage de bootstrap) avec un premier moteur de modèles maison (en attendant de passer tout ça sur Slim).

    On a créé un système d’authentification maison, basé sur JWT. Ça rend pasteque-server plus simple à installer. D’ailleurs, un installateur graphique est en cours de test et devrait sortir à l’occasion d’une version mineure. P’têt qu’un jour il y aura un framaPOS, va savoir…

    Nouveaux logiciels de la suite

    On a vu naître de nouveaux logiciels : pasteque-tools, une série d’utilitaires pour le développement autour de Pastèque, pasteque-catalog, qui vise à offrir un catalogue intégrable à un site Web, etc.

    Le turfu technique

    Les obligations légales de la loi de finances 2016 vont imposer une série de modifications techniques, ce sera la version 8. Cette version ne se concentrera que sur les adaptations nécessaires à cette loi de finances. Toute amélioration fonctionnelle ne serait qu’une conséquence de la LF 2016. J’espère qu’on est clair : on va tenter d’être dans les clous.

    Nous allons donc scinder pasteque-server en deux logiciels (pasteque-api et pasteque-administration), le gros de la conformité LF 2016 sera évidemment assuré par pasteque-api. On va en recauser plus bas.

    Nous allons mettre en place des outils de vérification de non‐modification des sections‐clefs du logiciel. Le but est de faciliter la vie de ceux qui bidouillent leurs logiciels, tant qu’ils ne touchent pas aux sections‐clefs. Ça a déjà été mis en place par eldy pour Dolibarr…

    Une fois tout ça validé, on pourra recommencer à rigoler en version 9.

    Ça peut paraître con dit comme ça, mais dans tout logiciel, il y a toujours une personne qui arrive avec une idée qui va du totalement bidon au truc indispensable, et qu’il faut gérer. Actuellement, on répond très simplement : toute suggestion de fonctionnalité, ça sera la v9 ; et la v9, c’est pas pour demain. Si t’es pas content, il y a des logiciels privateurs moins biens et plus chers. :)

    Petit point loi de finances 2016

    On a beaucoup bossé au sein de l’April sur la loi de finances 2016 et les obligations qui en découlent. Un texte devrait prochainement être publié à ce sujet.

    C’est un texte vachement bien, rédigé par ceux qui se sont énormément impliqués dans les échanges avec le gouvernement et qui ont décortiqué la loi et ses décrets d’application. Quand il sera publié, lisez‐le. Il contient des passages intéressants, comme l’analyse de la définition d’un éditeur de logiciels : cette notion n’avait jamais été définie avant, alors même qu’elle est déjà présente dans plusieurs textes de loi !

    Revenons à nos moutons et à nos obligations.

    Côté utilisateur

    Vous devez utiliser soit un logiciel certifié (il y a gros logo de certification dessus), soit un logiciel attesté (la personne qui vous a fourni le logiciel vous a également fourni un document attestant que le logiciel est légal). C’est à vous, utilisateur, de vérifier que c’est le cas.

    Vous pouvez modifier le logiciel, tant que vous ne touchez pas à certaines sections‐clefs (sécurisation, conservation, inaltérabilité et archivage des données). Si vous touchez à ces sections, vous devrez soit refaire certifier le logiciel, ça coûte un bras, soit trouver quelqu’un pour attester le logiciel à votre place.

    Ça peut paraître con, mais c’est une entrave à la liberté de modification…

    Côté éditeur

    L’éditeur, c’est celui qui sera assez fou pour émettre les attestations de conformité du logiciel. Il doit en émettre une, individualisée, pour chaque utilisateur du logiciel. Pas de flou, ça doit correspondre au modèle décrit dans un bulletin officiel.

    Vous pouvez distribuer un logiciel non certifié ou sans distribuer d’attestation. Un commerçant n’aura simplement pas le droit de l’utiliser en France.

    L’éditeur qui cependant fait certifier ou atteste de son logiciel devient ainsi co‐responsable de toute fraude rendue possible par son logiciel, que ce soit par des fonctionnalités ou des bogues, ou encore des bogues qui sont des fonctionnalités (Bill Gates 4ever <3).

    L’attestation saute si une des sections‐clefs du logiciel est modifiée. Comme c’est compliqué à prouver, petit pro‐tip, indiquez clairement dans les en‐têtes des fichiers concernés qu’il faut faire gaffe. Et puis distribuez un kit permettant de calculer et comparer rapidement les signatures des fichiers ou des binaires ; ça épargnera de la peine à tout le monde.

    C’est du boulot, mais le logiciel d’encaissement est une activité réglementée à présent ; this is serious business.

    Lire les commentaires

  • Charles P. Thacker (concepteur du Xerox Alto et contributeur à l'invention d'Ethernet) bronsonisé (Journaux LinuxFR)

    Puisque les journaux servent parfois de rubrique nécrologique, je voulais annoncer que Charles P. Thacker a été bronsonisé.

    À lire l'article In Memoriam: Charles P. Chuck Thacker: 1943-2017 :

    Charles P. Thacker (« Chuck » pour ceux qui l'ont connu), a contribué à la mise au point de nombreux aspects de l'ordinateur personnel et a reçu le prix Turing en 2009 en reconnaissance de ses conceptions et réalisations avant-gardistes du premier ordinateur personnel moderne, ainsi que ses contributions à Ethernet et à la tablette numérique, est décédé lundi 12 juin à l'âge de 74 ans après une brève maladie.

    Lire les commentaires

  • Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens? (Journaux LinuxFR)

    Bonjour nal.

    Aujourd'hui me suis demandé pourquoi Jabber n'a pas le succès qu'il mérite, même chez les informaticiens.

    Il a pourtant de nombreux atouts:

    • Simple d'utilisation
    • Léger
    • Fédéré
    • Basé sur le protocole XMPP: un standard ouvert et bien documenté
    • Format d'adresse similaire à l'e-mail
    • Tout le monde peut fournir une adresse Jabber
    • Comptes et/ou clients remplaçable sans perdre ses contacts
    • Possibilité de créer un compte depuis le client (si le serveur choisi l'accepte)
    • Supporté par des clients variés, adaptés à différents usages
    • Supporte la connexion de multiples clients à un même compte
    • En cas de multiples connections, on peut gérer leurs priorités
    • Possibilité de recevoir une copie des messages reçus et envoyés sur tous ses clients connectés (cabron)
    • Historique stocké coté serveur et synchronisé entre les clients (MAM)
    • Discussions de groupe avec modérateurs et adresses cachées aux autres participants
    • Statut personnel accompagné d'un message
    • Statut des messages (envoyé, reçu et lu)
    • Envoi de sa position géographique à un contact.
    • Annuaire
    • Partage de fichier simple (http-upload)
    • Possibilité d'empaqueter la connexion dans de l'http (Bosh), pratique quand on est connecté depuis un réseau wifi pourri.
    • Conversation audio et vidéo
    • Signature et chiffrement de ses messages avec GPG et OTR
    • Signature de son status avec GPG
    • Possibilité pour le client de communiquer avec les bots, sans que l'utilisateur n'ai à taper de commandes
    • Passerelles vers d'autres services de chat (IRC, Telegram, etc)
    • Possibilité de découvrir, accéder et interagir avec les services proposés par le serveur et les contactes (bot ou pas)

    Coté client libre, il y a du choix:

    • Movim: Un client moderne, en version desktop, smartphone et web. Très complet, il propose même un système de "forums" via ce qu'il appelle les "communautés", un système d'actualités avec la possibilité de rédiger ses propres articles, le support de la syntaxe markdown. Les articles qu'on écrit sont même visiblex avec un simple navigateur web, pas besoin de compte Jabber.
    • Conversations: Un client léger, pour Android, qui se concentre sur les communications texte. Points négatifs: Il est payant sur le Google Store et la gestion des statuts est cachées sans raison.
    • Jitsi: Un client qui se concentre sur la vidéo-conférence, en version desktop, smartphone et web. Plutôt destiné à un usage pro.
    • Gajim: Le vénérable client desktop. Très complet, mais son interface date un peu.
    • D'autres que j'oublie.

    Pour le développeur de bot et l'admin système il y a aussi des points forts:

    • Jabber utilise le protocole XMPP: Du XML échangé par un socket TCP.
    • XMPP est standard, ouvert et bien documenté
    • De nombreuses bibliothèques implémentent ce protocole, certaines étant même tournées vers la création de bots
    • Les bases du protocoles existent depuis assez longtemps pour avoir été éprouvées
    • Le protocole est extensible, on peut le faire évoluer suivant les besoins
    • Prosody fourni un serveur très simple et modulaire. Rapide à déployer. Idéal pour une association, une PME ou un usage personnel. Écrit en lua, c'est un très bon choix si on a besoin de faire du dév coté serveur.
    • Ejabberd est quand à lui un serveur conçu pour les grosses infrastructures.
    • Possibilité d'envoyer un message de bienvenu aux utilisateurs et de les prévenir en cas de maintenance de serveur.

    Jabber est l'idéal pour une association libriste ou un hackerspace:

    • Serveur facile à déployer, demande peut de travail pour être maintenu
    • L'annuaire permet de retrouver rapidement un autre membre. On peut également pré-remplir la liste des contactes avec les autres utilisateurs du serveur.
    • On peut héberger son propre serveur de salons de discussion sur son propre domaine.
    • On profite de tous les avantages listés plus haut.

    Je peux comprendre qu'il soit très difficile d'avoir du succès auprès du grand public en matière de service de messagerie instantanée. Mais pourquoi Jabber, avec tout ses avantages, n'est-il pas plus utilisé par les informaticiens ou au moins les libristes et les hackers? Pourquoi une solution moins libre comme Telegram, malgré tous ses points
    négatifs, a-t-elle plus de succès?

    Lire les commentaires

  • Écrire des diagrammes de séquences (Dépêches LinuxFR)

    Les diagrammes de séquences sont très utiles pour représenter le déroulement d’événements au fil du temps. Ils sont par exemple très utilisés pour décrire des protocoles de communication, où les paquets d’information se croisent, se perdent, passent du temps dans les tuyaux.

    Dans la seconde partie de la dépêche, après avoir expliqué leur principe de ces diagrammes, quelques logiciels existants seront listés et un nouveau venu sera présenté.

    Les diagrammes de séquences sont très utiles pour représenter le déroulement d’événements au fil du temps. Ils sont par exemple très utilisés pour décrire des protocoles de communication, où les paquets d’information se croisent, se perdent, passent du temps dans les tuyaux.

    Ces diagrammes comportent :

    • des acteurs, avec leur ligne de vie (un acteur peut représenter une personne, une machine, un processus, un fil d’exécution…). La spécification UML utilise le terme de « participant » ;
    • des messages échangés entre acteurs.

    On fait ces dessins au tableau, puis on les efface, mais parfois on voudrait les inclure dans une page d’un document, ou les envoyer par courriel.

    Logiciels existants

    Des outils logiciels existent, pour générer de tels diagrammes :

    • éditeur de texte (ASCII art) ;
    • Mscgen (http://www.mcternan.me.uk/mscgen) ;
    • éditeurs dits UML ;
    • éditeurs SDL (Specification and Description Language) ;
    • éditeurs de diagrammes : Dia, LibreOffice, Microsoft Visio, etc. ;
    • outils d’ingénierie système (Capella…).

    Mais pour le moment, je ne suis pas satisfait de ceux que j’ai utilisés. Je voudrais les possibilités suivantes :

    • créer un acteur ou le détruire au cours du temps ;
    • croiser les échanges de messages ;
    • perdre un message ;
    • indiquer l’expiration d’un temps imparti (timeout) ;
    • faire une mise en page du dessin sans dessiner (j’entends par là que je ne veux pas passer trop de temps à déplacer à la souris les éléments pour les aligner ou les relier, et puis tout décaler un par un parce que j’ai inséré un nouvel acteur en plein milieu…) ;
    • avoir un logiciel libre et gratuit.

    Si quelqu’un connaît un tel logiciel, je suis preneur.

    Et alors ?

    En attendant, j’ai fait un prototype d’un tel logiciel, que j’appelle pour le moment meseq sur le principe de mscgen :

    • on écrit un fichier texte décrivant le scénario ;
    • meseq génère une image PNG à partir de ce fichier.

    L’avantage de cette approche est la simplicité et la rapidité de développement de l’outil, mais l’inconvénient est que c’est moins ergonomique qu’un éditeur avec rendu WYSIWYG.

    J’ai mis au point une syntaxe rudimentaire pour le fichier d’entrée. Je sais déjà que je vais la modifier pour la rendre plus évolutive.
    Voici un exemple pour illustrer cette syntaxe (fichier .msq) :

    [init]
    actors w3client proxy "" w3server
    
    [scenario]
    
    w3client   ->   proxy   CONNECT
    w3client   <-   proxy   OK
    w3client   ->   proxy   bytes
    proxy      ->   w3server bytes
    :
    w3client  <->   w3server "TLS Handshake\nwhat follows is ciphered"
    :
    :
    w3client   ->    proxy   "GET /index.html"
    proxy      ->   w3server "GET /index.html"
    proxy      <-   w3server "200, index.html"
    w3client   <-    proxy   "200, index.html"
    

    Et voici l’image générée par meseq (plus complète que l’exemple ci‐dessus) :

    example_web.msq.png

    Autre exemple, avec flèches qui se croisent, etc. :

    example_piggyback.msq.png

    Show me the prototype

    Ce prototype est là pour étudier la faisabilité, présenter mes idées et expérimenter.
    Bon, il est codé vite et mal : non documenté, bogué, mal structuré… Bref, un vrai code de goret.

    Ce prototype et les exemples sont sur Github : https://github.com/goeb/meseq.

    On utilise les bibliothèques Cairo et Pango pour dessiner, écrire le texte, puis générer l’image. Elles sont relativement simples à utiliser.

    Il existe d’autres bibliothèques pour dessiner, que je n’ai pas étudiées (et je ne suis pas sûr qu’il existe un moyen simple de les utiliser en Python) :

    • libgd, utilisée par mscgen ;
    • les bibliothèques sous‐jacentes de Graphviz (dont le rendu est agréable).

    Pour la suite

    Les améliorations à faire sont :

    • améliorer le rendu (diagramme plus compact verticalement, réduire les conflits de textes qui se superposent…) ;
    • ajouter des visuels (bloc de commentaire, couleurs…) ;
    • augmenter la qualité de code ;
    • choisir une licence libre.

    Par la suite, je porterai peut‐être ce programme en C ou C++, afin qu’il soit plus facile d’accès pour les personnes ne disposant pas de Python sur leur poste (je pense aux personnes lambda sur système d’exploitation Windows).

    Afin d’orienter les choix qui restent à faire, je serais intéressé par les avis éclairés des lecteurs de LinuxFr.org :

    • utilisez‐vous les diagrammes de séquences ?
    • quels éléments visuels trouvez‐vous indispensables, et pour représenter quoi ?
    • faut‐il rester en Python ou passer en C ou C++ ?

    N. D. M. : voici une liste des liens apparus dans les commentaires du journal :

    Lire les commentaires

  • Runtastic et la protection des données (Journaux LinuxFR)

    Pour ceux qui courent et qui traque un peu leur performance, il existe sur le marché plusieurs fournisseurs d'application smartphone/web pour garder ses trajets et faire des statistiques.

    Dans mon cas, j'ai choisi Runtastic (runtastic.com).

    En plus de l'application sur mon téléphone que j'utilisais au début pour le gps et écouter de la musique en même temps, j'ai fini par commander la montre GPS de la marque qui fait aussi cardiofréquencemètre, en vérifiant que cela fonctionne sous Linux, ce qui est le cas (j'ai trouvé un outil qui permets d'extraire les run).

    Réception du paquet, déballage de la montre, petite course et utilisation de https://github.com/mru00/crane_gps_watch pour extraire les fichiers .tcx ca marche nickel.

    Je dois juste manuellement uploader mon fichier pour l'ajouter à mon profil runtastic depuis leur interface web.

    Pour ne pas mourir idiot, je me dis que je vais tester leur petite application qui est censée directement uploader mes courses depuis la montre vers mon compte runtastic, seul limitation windows, j'ai deux VM dispo, une en windows7 et l'autre en Windows10.

    Et la c'est le drame, après m'avoir demandé mes credentials, mon navigateur web s'ouvre et je me trouve avec l'aperçu d'une page qui ne correspond pas à mon compte, mais à la page d'un autre compte. J'ai son nom, sa position géographique. ARGH. Je me dis que ma montre n'est pas neuve et quelle contient peut-être des données de l'ancien propriétaire. La montre a été achetée dans un magasin relativement fiable et les scéllés sur la boîte étaient intactes. De plus la montre ne présente aucune marque particulière ce qui finit de me convaincre qu'elle est neuve.

    Je fais un reset to factory, je désinstalle, réinstall et rebelote, je me retrouve sur la page d'un compte qui n'est pas le mien. Je tente une installation sur l'autre VM pour être sur qu'aucune trace n'a subsisté sur la machine malgré la désinstallation et idem.

    Je décide de sortir l'artillerie lourde et essayer de comprendre comment ca marche.
    Ce petit exercice de reverse engineering m'a fait froid dans le dos.

    Donc, je me mets sur l'hôte de ma VM, et un petit coup de ngrep sur l'interface réseau bridgée, me permet d'intercepter les requêtes faites par l'application. J'entends déjà les murmures dans l'assemblée: "pff SSL toussa verra rien…"

    Em, comment dire, je vois passer un magnifique POST en json avec un id de type DEADBEEF qui correspond vraisemblablement à l'id de la montre en clair. 2017 quoi. Ensuite, un magnifique GET en retour qui contient le nom, le prénom et en plus l'email de l'autre compte. Un petit WTF s'impose.

    A la base j'avais choisi Runtastic pour leur politique de confidentialité, ils avaient l'air de garder les données pour eux. Je n'avais pas fait l'évaluation des différents produit sur le marché en fonction de la qualité de leurs API…

    Pour rajouter une couche depuis ce jour, j'ai régulièrement des courses de cet utilisateur mystère qui s'ajoutent à mon profil. Mais pas seulement, j'ai aussi des courses qui n'ont rien à voir, car il s'agit de run en Moldavie ou bien d'autres pays hors Europe.

    J'ai bien évidemment contacté le support. Il m'ont envoyé une autre montre que je n'ai pas l'intention d'utiliser car bon, même s'il y a un problème avec la montre, ça ne réglera pas les ajouts d'autre courses dans d'autre pays. Surtout pendant des périodes ou moi même je n'ai pas couru. Ils ont l'air à la ramasse. Le problème dure depuis le mois de Janvier et je ne consacre pas un temps énorme à la résolution du problème, j'ai autre chose à faire, ville de famille, boulot entre autre.

    Bref, je profite de ce journal pour vider un peu mon sac et partager cette petit expérience intéressante. Je vais voir jusqu'où va aller cette histoire. Le dernier mail que je leur ai envoyé dit en résumé: Je vois encore et toujours de courses qui ne sont pas à moi. Faites que ca cesse.

    Je vais résilier mon compte (je suis premium member, et j'étais content de leur service jusque là), le temps de trouver un moyen d'extraire l'existant (sachant qu'aucune API n'est à disposition pour cela).

    Donc éviter Runtastic et ne pas oublier de tester les API…

    Lire les commentaires

  • Openssh, dernières actus (Journaux LinuxFR)

    Salut journal,

    OpenSSH (OpenBSD Secure Shell ou ssh pour les intimes) est un ensemble d'outils informatiques libres permettant des communications sécurisées sur un réseau informatique en utilisant le protocole SSH.

    Et cet outil a une actu récente brûlante,
    Comme je ne l'ai pas vu ces derniers jours dans linuxfr, je le pose là :
    https://access.redhat.com/blogs/766093/posts/3051131

    Attention c'est du sshpr0n - littéralement - au menu :

    • Simplification de la configuration des proxy avec le nouveau paramètre ProxyJump
    • Forward des Unix socket (oui oui!)
    • Simplification de la configuration de ssh-agent (fini les scripts pourris)

    Plus d'autres trucs trop nerdy (crypto, fingerprint, privileges) pour m'extasier…

    Voilà voilà,

    Lire les commentaires

  • Effacement des doublons et historique complet pour Fim 1.2.2 (Dépêches LinuxFR)

    Fim (File Integrity Manager) sort dans sa version 1.2.2 avec diverses améliorations et un support de présentation en français.

    Fim est un gestionnaire de fichiers libre (licence GPL v3) qui permet de gérer beaucoup de fichiers de n’importe quelle taille. Il peut, par exemple, gérer des musiques, des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et les effacer.

    Fim Logo

    French slides

    Les nouveautés depuis la version 1.2.0

    Général

    • ajout d'un support de présentation en français et en anglais ;
    • effacement des doublons avec la commande rdup ;
    • amélioration de l’affichage de la commande de détection des doublons ;
    • la commande log affiche le détail de toutes les modifications sur les fichiers ;
    • allocation dynamique de files d’exécution pour « hacher » les fichiers en fonction du débit du disque, ce qui permet plus de files d’exécution dans le cas d’un SSD et moins pour un disque dur classique ; ce mode de fonctionnement est activé par défaut ;
    • la commande diff est dépréciée en faveur de la commande status ;
    • l’option -c est dépréciée en faveur de l’option -m ;
    • la commande rdup utilise maintenant l’option -M.

    Corrections de bogues

    • détection correcte en mode « super‐fast » des fichiers qui grossissent ;
    • commentaires avec espaces supportés sous Windows ;
    • diverses corrections, plus de détails dans le journal des modifications.

    Lire les commentaires

  • Meetup le 28 Mars 2017 à Grenoble "Créer sa distrib' Linux embarqué avec les outils Yocto" (Journaux LinuxFR)

    Le groupe Rhone Alpes Embedded Systems Meetup organise une rencontre sur le thème "Créer sa distribution Linux embarqué avec les outils Yocto / Angström" le 28 Mars 2017 en soirée à Grenoble. Cette soirée sera divisée en 2 parties : une présentation d'environ 1h30 suivie d'un temps d'échanges entre les participants autour d'un buffet.

    L'objectif est de permettre aux participants de découvrir comment créer sur mesure une distribution Linux adaptée à son projet embarqué, et d'échanger expériences et bonnes pratiques. La présentation sera effectuée par Christian Charreyre, expert Linux embarqué et formateur chez CIO Systèmes Embarqués.

    La manifestation se déroule dans les locaux du Totem à Grenoble (adresse précise sur la page dédiée au meetup). Elle est entièrement gratuite mais nécessite une inscription auprès du groupe.

    L'agenda de la partie présentation est le suivant :

    • Contexte technique et business :
      - évolutions techniques : 10 ans de Linux en embarqué
      - évolutions des besoins produits : TTM, richesse fonctionnelle
      - le couple fort des smart devices : ARM + Linux
      - le challenger Android
      - quelques arguments en faveur d’une solution Linux plutôt qu’Android

    • Nécessité d’un outil dédié aux distributions embarquées :
      - gestion de l’arbre des dépendances des composants logiciels ;
      - reproductibilité des générations des images ;
      - isolation entre logiciels du poste développeur et de la cible ;
      - les principales solutions : Buildroot, LTIB, Scratchbox 2, OpenEmbedded/Angstrom/Yocto.

    • Utilisation de Yocto / Angström :
      - workflow de Yocto ;
      - sources amont : recettes et logiciels upstream ;
      - produits aval : images, paquets, SDK, récapitulatif des licences ;
      - moteur bitbake ;
      - tâches élémentaires de création d’un composant logiciel ;
      - structuration en couches ;
      - anatomie des recettes ;
      - création d’une image à partir de l’existant ;
      - création de recettes nouvelles ;
      - adaptation de recettes existantes ;
      - gestion des versions ;
      - création d’un BSP pour un nouveau hardware ;
      - reproductibilité et isolation.

    Lire les commentaires

  • Extraire les sous-titres des enregistrements de la TNT HD (Journaux LinuxFR)

    Avec la fin de la définition SD pour la TNT en France, il devenait urgent pour l'amateur de VOST que je suis de comprendre comment récupérer les sous-titres des flux HD, le brave Project X ne traitant à ma connaissance que les flux SD.

    En fait, l'outil miraculeux existe, il s'appelle SubtitleEdit, mais malgré des recherches fréquentes, je n'ai appris son existence que récemment.
    En plus, il y a une petite astuce à utiliser, car il ne reconnait pas directement les flux de sous-titres de mes enregistrements au format ts (alors que dans la doc, on a l'impression que oui), cependant on s'en sort en extrayant le flux soi-même avec ffmpeg.

    J'explique les manipulations sous Ubuntu, mais ce n'est pas très distribution-dépendant.

    Installation

    1) quelques paquets à installer:
    sudo apt-get install ffmpeg mono-complete libhunspell-dev tesseract-ocr-fra tesseract-ocr-deu

    2) Télécharger SubtitleEdit
    https://github.com/SubtitleEdit/subtitleedit/releases
    Il faut choisir la version portable
    Aujourd'hui, c'est le fichier SE3411.zip qui convient

    3) Dézipper le fichier zip dans votre répertoire utilisateur
    s'y rendre, puis
    cd Tesseract/tessdata
    ln -s /usr/share/tesseract-ocr/tessdata/fra.traineddata
    ln -s /usr/share/tesseract-ocr/tessdata/deu.traineddata

    Ceci pour bénéficier de reconnaissance de caractère plus adaptée pour allemand, français.

    Utilisation

    1) On repère la piste de sous-titres voulue avec
    ffmpeg -i fichier.ts

    2) On extrait la piste avec ffmpeg
    numero= # ce que vous avez repéré
    ffmpeg -i fichier.ts -map 0:$numero -scodec copy fichier_extrait.ts

    3) On lance SubtitleEdit
    mono repertoire_de_l_executable/SubtitleEdit.exe fichier_extrait.ts

    La fenêtre OCR de reconnaissance de caractère s'ouvre automatiquement.
    On lance la reconnaissance, après avoir sélectionné la langue, on ferme la fenêtre OCR, puis on sauve au format de sous-titres voulu. C'est fini !

    Lire les commentaires

  • Sortie de GHC 8.2.1 (Dépêches LinuxFR)

    Une nouvelle version majeure du compilateur GHC pour Haskell est sortie.

    GHC

    Cette dépêche présente rapidement le langage Haskell, puis les nouveautés de la version 8.2.1 qui vient de sortir. En fin de dépêche, un exemple plus complet d’un code Haskell est présenté afin de motiver à l’usage de ce langage.

    Sommaire

    Présentation d’Haskell et de GHC

    Haskell est un langage de programmation fonctionnelle. Je vous invite à lire la dépêche de la sortie de GHC 8.0.1 qui réalise une présentation plus complète du langage.

    Une reformulation de la page de présentation du langage pourrait être la suivante :

    • Haskell est un langage statiquement typé, chaque expression a un type qui est déterminé à la compilation et le compilateur s’assure que l’assemblage d’expressions a un sens ; ceci permet de fournir quelques garanties sur le programme, mais cela permet aussi beaucoup d’expressivité.
    • Haskell est un langage au typage inféré, cela signifie que tous les avantages du typage statique viennent gratuitement, sans devoir écrire de déclaration complexe de type ;
    • Haskell est purement fonctionnel, c’est un des langages (sans parler des langages dérivés d’Haskell ou d’un de ses ancêtres, Miranda, purement fonctionnel et à évaluation paresseuse) qui a cette propriété où, de façon simplifiée, les effets de bords apparaissent explicitement ;
    • Haskell est concurrent, GHC, son compilateur le plus connu propose des primitives efficaces pour la concurrence et est capable d’exploiter tous les cœurs de calcul d’une machine ;
    • Haskell est rapide : dans certains cas, on peut approcher les performances de langages comme C++ ;
    • Haskell est paresseux, c’est un des rares langages à ma connaissance ayant cette caractéristique ;
    • Haskell vient avec de nombreux paquets pour de nombreuses applications.

    À mon avis, Haskell / GHC est un outil intéressant à regarder, car il est un des rares langages « grand public » à proposer certaines fonctionnalités, comme la séparation explicite des effets de bord ou l’évaluation paresseuse. En outre, Haskell propose un système de type très puissant permettant de modéliser son domaine de travail de façon élégante. Il s’agit d’un outil capable dans beaucoup de domaines, allant du Web au HPC, proposant de très bonnes performances et une sécurité accrue.

    Changements

    Comme d’habitude, de nombreux bogues et autres subtilités ont été réglés. J’ai essayé de résumer dans cette section les points que je trouve intéressants dans les notes de mise à jour.

    Mon changement préféré est que le compilateur affiche maintenant ses messages d’erreur avec de la couleur et un petit symbole montrant la zone de l’erreur.

    Performance

    Un des gros apports de cette 8.2.1 concerne la performance du compilateur qui est annoncé comme plus rapide, mais les notes de versions sont pauvres d’informations à ce sujet.

    De nombreux points visant les performances du code exécuté ont été traités, certains sont discutés dans les points suivants.

    Join points

    Les « join points » sont décrits sur le wiki et dans cette vidéo de Simon Peyton Jones : Compiling without continuations.

    Il s’agit d’une optimisation permettant de détecter plus de code sujet à être transformé en appel récursif terminal, ceci permettant une réduction non négligeable des allocations, puisqu’un appel récursif terminal se résume à peu de choses près à un saut dans le programme.

    Compact regions

    Un des gros reproches faits à la gestion de mémoire par ramasse‐miettes est le temps que peuvent prendre les phases de collection de mémoire. Dans le cas d’Haskell, l’implémentation choisie est en mode « stop the world », dit autrement, tout s’arrête pendant la phase de récupération de la mémoire. Cette phase peut être longue car toute la mémoire utilisée par le processus doit être scannée pour mettre à jour la liste des objets vivants ou morts, et ceci peut introduire des pauses peu acceptables dans certains contextes temps réel.

    GHC 8.2 propose les compact regions qui sont des espaces de stockage d’objets qui ne font pas référence à d’autres objets en dehors de cet espace. Ainsi le ramasse‐miettes peut ignorer cet espace pendant sa phase de parcours de la mémoire pour un gain de temps proportionnel à la quantité de mémoire qui n’a pas été parcourue.

    Point intéressant, une région compacte peut être sérialisée sur le disque de façon efficace.

    Types somme unpacked

    La représentation en mémoire d’un objet hiérarchique en Haskell dans GHC est composée de nombreuses indirections de pointeurs qui consomment de la mémoire et coûtent cher en performance du fait de l’absence de localité et d’un stress supplémentaire sur le ramasse‐miettes.

    Le travail sur l’extension UnpackedSumTypes permet de représenter plus efficacement les types somme (c.‐à‐d. les enums).

    NUMA

    Des optimisations pour les architectures NUMA sont en place. Pour rappel, les architectures NUMA ont des zones de la mémoire qui sont privilégiées par certains cœurs de calcul. Ainsi, il est plus efficace d’allouer la mémoire nécessaire pour un cœur dans une zone proche de celui‐ci.

    Meilleure gestion du format DWARF

    Le format DWARF est utilisé par de nombreux outils de debug ou d'analyse de performance comme gdb, valgrind, perf. L'amélioration de sa gestion permet, entre autres, une meilleure prise en charge de ces outils.

    Pour information, perf est un outil qui permet de faire du profiling statistique de tout programme. Au lieu d'instrumenter le code pour compter très précisément les appels de fonctions, ce que pourrait faire un compilateur, perf se contente de regarder l'état du programme à différent instants.

    Cette méthode de profiling a de nombreux avantages. Elle ne nécessite pas de recompiler le code source pour ajouter l'instrumentation et ainsi elle ne modifie pas l'exécution du programme. Les résultats sont plus pertinents qu'une méthode avec instrumentation car celle-ci peut avoir un coût qui biaise les résultats. Elle permet aussi de lancer le profiling sur un programme qui s'exécute déjà.

    Malheureusement, GHC génère des programmes avec un modèle d’exécution bien différent de ceux des langages plus traditionnels, d'où la difficulté d'utiliser ces outils. La page du wiki GHC sur DWARF détaille ces problématiques et les améliorations réalisées dans GHC 8.2.

    BackPack

    BackPack vise à proposer un système de module plus puissant.

    On rappelle qu'en Haskell il existe une quantité impressionnante de types pouvant représenter une chaîne de caractères :

    • String, qui n'est autre qu'une liste chaînée de caractères Unicode. ([Char]). Celle-ci est déconseillée pour la gestion de vraie chaîne de caractères, du fait du coût en mémoire et des performances associées aux listes chaînées.
    • Text, qui est une représentation compacte de chaînes Unicode. Performante, elle est cependant critiquée par son choix de l'encodage interne — utf-16 — du fait du surcoût en mémoire comparé à de l'utf-8. Ce type vient en version stricte et paresseuse.
    • ByteString, qui est une représentation compacte de suite d'octets. Utilisée principalement pour les interactions binaires, elle vient en version stricte et paresseuse.
    • les Foundation String qui se veulent une alternative au Text en utilisant le codage interne en utf-8.

    Il en existe sûrement d'autres.

    Bref, c'est la jungle, car chaque type a son utilité en fonction de ses besoins en traitement correct des caractères, en traitement binaire, en évaluation paresseuse ou stricte.

    Avant BackPack, faire un module gérant les différents types de chaîne de caractères disponibles dans Haskell revenait à devoir faire autant de modules que d’implémentations à gérer… bonjour la duplication de code.

    Grâce à BackPack, les modules peuvent être paramétrés par une interface de type, permettant une implémentation générique du module. C'est très similaire aux modules paramétrés de OCaml.

    Stratégie de dérivation

    Haskell propose un mécanisme de dérivation de comportement automatique. Par exemple :

    data Vector = Vector {
        x :: Float,
        y :: Float,
        z :: Float
        } deriving (Show, Eq)

    Crée une classe Vector, représentant un triplet de flottant. La clause deriving permet au compilateur d'écrire automatiquement les fonctions d'affichage des égalités, par exemple :

    >>> v = Vector 1 2 3
    >>> v
    Vector {x = 1.0, y = 2.0, z = 3.0}
    >>> v2 = Vector 4 5 6
    >>> v == v2
    False
    >>> v == v
    True

    On peut aussi imaginer dériver automatiquement les comportements de séralisation, hash, conversion avec JSON, …

    Ce mécanisme a évolué au cours de la vie de Haskell, au départ il permettait de ne dériver que certains comportements fixes proposés par le compilateur. Puis de nouveaux comportements ont été ajoutés. Puis il est devenu possible pour un utilisateur de proposer son propre système pour dériver automatiquement des comportements. Du fait de la profusion de mécanismes de dérivation, certains cas sont devenus ambigus.

    GHC 8.2 fait un peu le ménage en proposant DerivingStrategies qui permet de choisir explicitement la stratégie à utiliser. Cet article résume le problème et démontre la solution.

    Amélioration du typage dynamique

    Haskell est un langage au typage statique, à ce titre il prend en charge bien évidemment la notion de typage dynamique par le biais du module Data.Dynamic.

    On peut encapsuler n’importe quel type dans un type Dynamic, mais pour le récupérer il faudra explicitement fournir le bon type :

    Prelude Data.Dynamic> a = toDyn "Hello"
    Prelude Data.Dynamic> b = toDyn True
    Prelude Data.Dynamic> :type a
    a :: Dynamic
    Prelude Data.Dynamic> :type b
    b :: Dynamic
    Prelude Data.Dynamic> (fromDynamic a) :: Maybe String
    Just "Hello"
    Prelude Data.Dynamic> (fromDynamic a) :: Maybe Bool
    Nothing
    Prelude Data.Dynamic> (fromDynamic b) :: Maybe String
    Nothing
    Prelude Data.Dynamic> (fromDynamic b) :: Maybe Bool
    Just True

    GHC 8.2 apporte l'implémentation du papier A reflection on types de Simon Peyton Jones, Stephanie Weirich, Richard A. Eisenberg et Dimitrios Vytiniotis, détaillé dans cette vidéo de SPJ. Ces changements ne seront pas forcément visibles pour un utilisateur final, mais ils simplifient et sécurisent l'implémentation de bibliothèques comme Dynamic en remplaçant un hack (un cast) par une opération garantie par le compilateur.

    Overloaded record fields

    La situation des record, i.e. des structures avec des champs nommés, n'est pas parfaite en Haskell.

    Depuis GHC 8.0, beaucoup de travail est fait à ce sujet, notamment avec l'arrivée des extensions :

    • DuplicateRecordField qui permet de définir dans le même module deux types avec des noms de champs égaux.
    • OverloadedLabels qui permet de définir des labels, syntaxiquement #foo qui seront surchargés en fonction du type.

    GHC 8.2 va un peu plus loin et propose la classe HasField qui permet d'extraire un champ de record de façon polymorphique, par exemple getField @"x" v permet d'extraire le champ x de v quel que soit le type de v.

    Notez que GHC 8.2 est incompatible avec le code de OverloadedLabels de GHC 8.2 et qu'il faudra adapter son code.

    Un meilleur support du polymorphisme "levity"

    Richard A. Eisenberg - Levity Polymorphism (en anglais).

    En Haskell (et dans de nombreux autres langages), il existe des objets « boxés » et des objets non « boxés ». Par exemple, un Int# est représenté par un entier machine sur 64 bits, alors qu'un Int est représenté par un pointeur de constructeur, que l'on pourrait assimiler à un tag de type, et par un Int#, tout cela pour deux fois plus de mémoire.

    Généralement, on n'utilise pas les types "non boxés" et le compilateur optimise cela comme il peut. Cependant quand les performances sont attendues, il peut être intéressant d'écrire du code sur des types non "boxés" et à un moment, il devient important de pouvoir écrire des fonctions polymorphiques travaillant aussi bien sur des types "boxés" que "non boxés".

    Exhaustivité des patterns

    Le nouveau pragma COMPLETE permet de forcer l'exhaustivité des patterns.

    Par défaut, chaque type crée aussi un pattern utilisable pour construire / déconstruire le type :

    data Point = Point Float Float deriving (Show)
    
    isOrigin (Point 0 0) = True
    isOrigin _ = False
    
    getX (Point x _) = x
    
    translate (Point x y) (dx,dy) = Point (x + dx) (y + dy)

    Il est cependant possible de créer ses propres patterns pour créer de nouvelles façons de construire / déconstruire ses types :

    {-# LANGUAGE ViewPatterns #-}
    {-# LANGUAGE PatternSynonyms #-}
    
    pattern PolarPoint r phi <- (\ (Point x y) -> (sqrt (x*x+y*y), atan2 y x)) -> (r, phi) where
        PolarPoint r phi = Point (r * cos phi) (r * sin phi

    Ici, je crée un pattern PolarPoint r phi qui représente un point en coordonnées polaires. On peut s'en servir autant pour créer que pour déconstruire :

    > PolarPoint 10 0
    Point 10.0 0.0
    > PolarPoint 10 (pi / 2)
    Point (-4.371139e-7) 10.0
    > PolarPoint r angle = Point 2 2
    > r
    2.8284271247461903
    > angle
    0.7853981633974483

    Cependant, avant GHC 8.2, le compilateur râlait sur les fonctions utilisant ce pattern :

    -- | Retourne `True` si le point est plus loin qu'un rayon de 10
    isFar :: Point -> Bool
    isFar (PolarPoint r _) = r > 10
    Polar.hs:18:1: warning: [-Wincomplete-patterns]
        Pattern match(es) are non-exhaustive
        In an equation for ‘isFar’: Patterns not matched: _
       |
    18 | isFar (PolarPoint r _) = r > 10
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    

    En effet, le compilateur ne peut pas prouver tous les cas de figure des patterns, ce qui se traduit par beaucoup de faux positifs dans lesquels les vrais positifs sont cachés, rendant cette fonctionnalité peu utilisable.

    Depuis GHC 8.2, l'utilisateur peut fournir une directive de compilation {-# COMPLETE PolarPoint #-} permettant de spécifier que le pattern PolarPoint couvre tous les cas de figure.

    L'écosystème

    Stack est un outil de gestion de dépendance pour Haskell. Il peut sous-traiter à Nix pour les dépendances non Haskell, permettant ainsi la compilation dans un environnement contrôlé. Pour faire simple, un programme Haskell peut être compilé en une seule ligne de commande stack build sans devoir se préoccuper de l'installation de dépendances.

    L'utilisation de Stackage qui fournit des snapshots de packages versionnés garantit qu'un programme compilé il y a quelques mois le sera dans les mêmes conditions.

    Stack a gagné dernièrement une nouvelle commande script qui permet d’exécuter un programme Haskell comme un script en installant les dépendances listées dans le script lui-même. Nous verrons un cas d'usage dans la section d'exemples plus loin.

    Le futur

    Haskell (et GHC) évolue constamment. Cette section liste quelques projets excitants pour l'avenir.

    Typage dépendant

    Cet article de blog détaille le travail sur les types dépendants en Haskell qui devrait arriver plus ou moins rapidement, l'auteur parlant de GHC 8.6.

    Les Types dépendants permettent d'enrichir le système de type afin de garantir plus de choses.

    Pour expliciter cela, nous allons traiter un petit problème de multiplication de matrices.

    Soit un type Matrice qui pourrait être représenté comme suit en Haskell :

    data Matrice = Matrice {
         nLignes :: Int,
         nColonnes :: Int,
         donnée :: (... structure non détaillée ...)
    }

    Le produit matriciel est une opération classique d’algèbre qui s'effectue entre deux matrices et renvoie une nouvelle matrice. Cependant il y a une contrainte entre la taille des matrices d'entrées et le résultat de la matrice de sortie. Une matrice de taille (m, n) ne peut être multipliée que par une matrice de taille (n, p) pour obtenir une matrice de taille (m, p).

    Bien souvent cette contrainte est assurée par une vérification à l’exécution :

    produitMatrice :: Matrice -> Matrice -> Matrice
    produitMatrice (Matrice m n dataA) (Matrice n' p dataB)
        | n == n' = (Matrice m p (... calcul non détaillé ...))
        | otherwise = error "Pas les bonnes tailles"

    Il est à l'heure actuelle possible en Haskell de spécifier ces tailles directement dans le type, tel que :

    data Matrice nLignes nColonnes = Matrice {
          donnée :: (... structure non détaillée ...)
       }

    Donnant ainsi le produit suivant :

    produitMatrice :: Matrice m n -> Matrice n p -> Matrice m p
    produitMatrice (Matrice dataA) (Matrice dataB) = Matrice (... calcul non détaillé ...)

    Cette approche force le compilateur à vérifier que les tailles de nos matrices sont correctes pendant la compilation, ce qui supprime totalement toute une classe d'erreur à l’exécution.

    Justin Le a rédigé une très bonne série d'articles qui traite de l'état actuel du typage dépendant en Haskell en implémentant un réseau de neurone multi couches.

    Une des limitations de cette approche est que les tailles, des réseaux de neurone ou des matrices de notre exemple, doivent être connue intégralement à la compilation, empêchant l'écriture d'un outil pouvant charger depuis le disque une matrice de taille quelconque.

    Dans la seconde partie de son article, Justin Le parle de ce problème et montre les solutions existantes pour réaliser ce type d'opérations. On peut donc écrire une fonction de chargement de matrice depuis le disque avec des tailles statiques :

    chargerMatrice :: Filename -> IO (Matrice n m)

    Je ne détaillerais pas la solution, c'est, à mon avis, lourd et rébarbatif. Le travaille sur le typage dépendant qui est en cours dans GHC vise à simplifier cela.

    Typage linéaire

    Le typage linéaire devrait arriver sous peu dans GHC. Ce travail est en grande partie réalisé par une société française, tweag.io, donc cocorico ;) On note leur publication sur les types linéaires et leur premier article de Blog expliquant le projet.

    Les types linéaires apportent à la fois un potentiel de performance et de sécurité / modélisation.

    Pour simplifier, c'est une façon de dire qu'une valeur ne sera utilisée qu'une et une seule fois. Je ne rentrerai pas dans les détails de son implémentation en Haskell puisque c'est tout nouveau et que les choses peuvent beaucoup bouger, je me contenterai de donner deux exemples de problématiques que les types linéaires peuvent résoudre.

    Sécurité et modélisation

    Cet article de Blog détaille ce point, l'exemple qui suit est similaire.

    Quand on utilise des sockets, on peut faire de nombreuses actions en fonction de l'état de la socket, qui sont résumées dans le graphe suivant:

    Non initialisée ---bind()---> En attente ----listen()---> En écoute
         \                                                     /
          \                                                   accept()
           \-----connect()----> Envoyer/Recevoir  <==========/
    

    Ici, une flèche simple représente un changement d'état de la socket. Et la flèche === représente le fait que la fonction accept retourne une nouvelle socket directement dans l'état d'envoi et de réception de message.

    À chaque état est associé une liste d'opérations possibles, par exemple recv et send ne sont possibles que dans l'état de transfert.

    On pourrait modéliser ces états par des types différents :

    data NonInitSocket = NonInitSocket Int
    data AttenteSocket = AttenteSocket Int
    data EcouteSocket = EcouteSocket Int
    
    data TransfertSocket = TransfertSocket Int

    L'Int représentant le descripteur de fichier bas niveau de la socket.

    Et à cela s'ajoute des fonctions :

    create :: IO NonInitSocket
    
    bind :: NonInitSocket -> Addr -> IO AttenteSocket
    listen :: AttenteSocket -> Int -> IO EcouteSocket
    connect :: NonInitSocket -> Addr -> IO TransfertSocket
    
    accept :: EcouteSocket -> IO TransfertSocket
    send :: TransfertSocket -> String -> IO ()
    recv :: TransfertSocket -> Int -> IO String
    closeEcoute :: EcouteSocket -> IO ()
    closeTransfert :: TransfertSocket -> IO ()

    Les IO matérialisant que chacune de ces fonctions réalise des effets de bord.

    Et là tout est beau dans le meilleur des mondes, on ne peut pas exécuter une fonction qui n'a pas de sens sur une socket qui n'est pas dans le bon état.

    Sauf que si… Observons le code suivant :

    fonctionBugée = do
       s <- create
    
       attenteSocket <- bind s anAddr
       ecouteSocket <- listen attenteSocket 3
    
       ...
    
       transfertSocket <- connect s anotherAddr

    Ici on voit qu’on se sert deux fois de s ce qui est faux puisque à ce moment le descripteur de socket qui est stocké dans s correspond à une socket en état d'écoute.

    On remarque aussi qu'on ne ferme jamais nos sockets.

    Les types linéaires peuvent ici nous sauver en refusant à la compilation le second usage de s. De même, la compilation pourrait refuser ce code qui n'utilise pas ecouteSocket ni transfertSocket, la seule façon de les utiliser étant de les fermer. Ainsi les types linéaires permettent de détecter à la compilation des mauvais usages de ressources.

    Performance

    Haskell est un langage où on maximise la non mutabilité. Ainsi on va préférer créer une nouvelle structure de données plutôt que d'en modifier une. Haskell tire profit de cette non mutabilité pour partager au maximum les parties communes entre plusieurs données.

    S'il existe des structures non mutables performantes (à lire, c'est très instructif), ce n'est pas le cas de toutes les structures. Ainsi, un vecteur n'est pas du tout adapté à la non mutabilité, car il faut recopier intégralement celui-ci en cas de modification d'une unique case.

    Une des premières choses qui vient à l'esprit c'est que si personne d'autre n'utilise la donnée, on pourrait la modifier sans scrupule. Cette information n'est cependant pas connue à la compilation et serait trop coûteuse à calculer lors de l’exécution.

    Les types linéaires permettent de garantir que notre valeur ne sera utilisée qu'une seule fois, sous peine de refuser de compiler. Cette information en main, une bibliothèque pourra proposer des fonctions optimisées avec mutation pour remplacer les fonctions qui copient. Et cela sans faire apparaître de mutation dans le code utilisateur.

    Exemple d'Haskell : le dîner des philosophes

    La fin de cette dépêche est consacrée à un exemple de résolution d'un problème en Haskell. Merci à jiehong de m'avoir soufflé l'idée de présenter la mémoire transactionnelle.

    Introduction

    Nous allons nous intéresser au problème des philosophes. Il s'agit d'un problème classique de programmation concurrente qui brille autant par son énoncé trivial que par le nombre de problématiques d’implémentation qu'il soulève.

    À une table ronde d'un restaurant italien, des philosophes discutent en mangeant. Chaque philosophe a à sa droite et sa gauche une fourchette, qu'il partage avec son voisin de droite et de gauche.

    Pour manger, un philosophe doit prendre les deux fourchettes, il pourra ensuite manger pendant un laps de temps variable, puis reposera les fourchettes. Cependant, en prenant les fourchettes, il empêche son voisin de droite et de gauche de manger.

    Le problème est donc d'ordonnancer le repas des philosophes en évitant des situations d'interblocage courantes tel que :

    • des « dead lock », où un philosophe sera en attente d'une fourchette prise par une autre philosophe lui-même en attente d'une autre fourchette. On peut imaginer une situation ou tous les philosophes sont bloqués de cette manière.
    • des « live lock », où les fourchettes changent de main en permanence, mais sans que personne ne puisse manger.

    Une solution simple à ce problème consiste en l'usage d'un verrou global. Chaque philosophe désirant manger va tenter de prendre le verrou global et une fois celui-ci verrouillé, il prendra ses deux fourchettes si et seulement si les deux sont disponibles. Cette solution est triviale à implémenter, mais ne passe pas à l'échelle, car elle séquence toutes les opérations de prise ou de dépose des fourchettes. Il faut donc employer une stratégie plus fine.

    Il existe de nombreuses solutions à ce problème, nombreuses sont complexes à implémenter, et impose une grande rigueur. Par exemple en s'assurant de ne prendre et rendre les verrous toujours dans le même ordre, on s'assure théoriquement qu'il n'y a pas d'interblocage, par exemple si un philosophe s'assure de prendre la fourchette gauche avant la droite. Mais il y a le cas du dernier philosophe de la table qui doit prendre sa fourchette droite avant la gauche, la fourchette droite étant en fait la première de la table. Bref, vous l'aurez compris, ce n'est pas trivial.

    Dans cet exemple de code Haskell, nous présenterons une solution utilisant les primitives de STM, "Software Transactional Memory", Mémoire transactionnelle logicielle. Cette technique offre de nombreux avantages, en termes de facilité de programmation et de composition du code.

    STM et Haskell

    En Haskell, nous pouvons créer une zone de mémoire modifiable par STM grâce à la fonction newTMVarIO. Cette zone contiendra ou pas une valeur. Grâce à putTMVar, nous pouvons mettre une valeur dans la zone. takeTMVar vide la zone et renvoie la valeur. Cette opération est bloquante.

    Nous pouvons représenter une fourchette par une TMVar () contenant simplement un (). On aurait pu mettre n'importe quoi dedans, la seule chose nous intéressant étant de savoir si la valeur est dedans ou pas.

    On peut composer ensemble un certain nombre d'opérations sur des TMVar et exécuter atomiquement le bloc grâce à atomically.

    Les STM divergent d'une stratégie plus classique à base de mutex par :

    • des opérations sont composables. On peut créer une action plus complexe à partir d'une ensemble de petits actions. Bien évidemment, plus l'action est complexe, plus la transaction a des chances d'échouer et de devoir recommencer.
    • les opérations atomiques ont une granularité très fine, car elles ne « verrouillent » que les variables impliquées dans la transaction. Ainsi on peut facilement imaginer modifier une structure de données en plusieurs points par plusieurs threads sans qu'il n'y ait de conflit.

    Exemple d’exécution

    Pour exécuter le programme, nous ferons appel à stack qui après installation des bibliothèques nécessaires va utiliser GHC en mode interprété, ce programme ne demandant pas de performance particulière.

    Le programme prend en paramètre le nombre de philosophes autour de la table. Chaque philosophe est nommé par une lettre. Quand celui-ci commence à manger, la console affiche une lettre majuscule, quand celui-ci s’arrête, elle affichera une lettre minuscule. Les philosophes essayent de manger pendant 30 secondes.

    Avec deux philosophes, on est en situation où seulement l'un peut manger :

    $ ./Philosopher.hs 2
    AaBbAaBbAaBbAaBbA
    

    Avec trois philosophes, seulement un peut manger

    $ ./Philosopher.hs 3
    AaBbCcAaBbCcA
    

    Avec quatre, c'est plus intéressant. Les philosophes ne peuvent manger ensemble que par groupes de 2, c’est-à-dire soit A et C, soit B et D. Ainsi, pour changer de groupe, il faut que les deux philosophes du même groupe arrêtent de manger en même temps. L’implémentation fait manger les philosophes pendant un temps aléatoire compris entre 0 et 2 secondes, et ils se reposent pendant 100 ms avant de recommencer à essayer de prendre les fourchettes. Ainsi, le moment ou les deux philosophes d'un groupe viennent de s’arrêter de manger ensemble est assez rare :

    $ ./Philosopher.hs 4
    ACcCaAcCaAcCaAcCcaBDdDdDbBdDbdACcaBDdDbB
    # ----------------| ICI
    

    Avec plusieurs philosophes, c'est bien plus drôle :

    $ ./Philosopher.hs 10
    ACEGIcgCGcCgGcaBiJjIeDgFbAiHdChIfGEgGeiEcICaAcCaAeiEIicICgGiIaAeEeEcCgGiIaAeEicICcCigH
    

    Implémentation

    Cette section détaille une solution en Haskell de ce problème. Des paragraphes d'explications s’intercalent entre les blocs de code qui peuvent être copiés collés en tant que tels dans un fichier Philosopher.hs.

    Prélude

    On commence par le Shebang décrivant interpréteur à utiliser. Ici stack. La ligne suivante liste les packages nécessaires pour ce fichier, à savoir stm pour l'usage de la mémoire transactionnelle, random pour générer des nombres aléatoires et optparse-generic pour lire la ligne de commande.

    #!/usr/bin/env stack
    -- stack script --resolver lts-9.0 --package "stm random optparse-generic"
    {-# LANGUAGE OverloadedStrings #-}

    Viennent l'import des modules nécessaires pour notre code. J'ai choisi d'importer de façon qualifier chaque fonction afin que le lecteur puisse connaitre sa provenance.

    module Main where
    
    import Control.Monad (replicateM, forever)
    import Control.Concurrent.STM (TMVar, putTMVar, takeTMVar, newTMVarIO, STM, atomically)
    import Control.Concurrent (forkIO, killThread, threadDelay, ThreadId)
    import System.Random (randomRIO)
    import Data.Char (toLower)
    import Options.Generic (getRecord)

    Fourchettes

    La gestion des fourchettes. En premier lieu, le type Fork qui représente une fourchette. Celui-ci contient un TMVar (), c’est-à-dire un conteneur STM qui peut contenir un (), c’est-à-dire « rien ». Mais on peut connaitre la présence ou l'absence de ce rien et c'est ce qui nous intéressera.

    data Fork = Fork (TMVar ())

    takeFork et releaseFork respectivement prennent et reposent une fourchette. takeFork sera bloquant. On note au type des fonctions que ces opérations s'effectuent sous le contrôle de la STM.

    -- | Prend une fourchette. Bloquant.
    takeFork :: Fork -> STM ()
    takeFork (Fork var) = takeTMVar var
    
    -- | Repose une fourchette. Non Bloquant.
    releaseFork :: Fork -> STM ()
    releaseFork (Fork var) = putTMVar var ()

    La création d'une fourchette avec mkFork implique la création d'une TMVar avec newTMVarIO :

    -- | Crée une fourchette
    mkFork :: IO Fork
    mkFork = do
      var <- newTMVarIO ()
      pure (Fork var)

    Ce morceau de code implique énormément de choses sur Haskell, nous allons nous y attarder un moment. Le type de la fonction est IO Fork, c'est une action d'entrée / sortie qui renvoie une fourchette. La première ligne réalise une action newTMVarIO () qui crée une nouvelle TMVar contenant un (). Celle-ci est stockée dans var. Il ne s'agit pas d'une égalité, mais d'une affectation, ici var est bien le résultat de l’exécution d'une action et non pas une égalité qui serait représentée avec le signe =.

    La valeur de retour de la fonction est Fork var c’est-à-dire la TMVar encapsulée dans le type Fork. Cette expression Fork var, de type Fork ne représente pas une action à effet de bord, ainsi elle ne peut pas être la valeur finale de la fonction (qui est de type IO Fork). Il faut donc encapsuler de nouveau le Fork dans une IO, est cela est fait grâce à la fonction pure.

    Ne vous en formaliser pas trop, c'est surprenant au début, mais on s'y fait vite.

    La création de n fourchettes se fait grace à la fonction replicateM qui réplique l'action mkFork et donc renvoie une liste de Fork. le M ici signifie que on réplique une action. Sinon on pourrait écrire replicate 3 True == [True, True, True] sans le M car True n'est pas une action.

    -- | `mkForks n` crée une liste de `n` `Fork` disponibles
    mkForks :: Int -> IO [Fork]
    mkForks n = replicateM n mkFork

    Philosophes

    Un philosophe est simplement une structure qui comprend un nom, sous la forme d'un Char, et deux Fork.

    -- | Un `Philosopher` est représenté par son nom et deux fourchettes
    data Philosopher = Philosopher Char Fork Fork

    La création de plusieurs philosophes, en se servant de fourchettes est la suivante :

    -- | Crée le nombre de philosophes associés aux fourchettes 
    mkPhilosophers :: [Fork] -> [Philosopher]
    mkPhilosophers forks = zipWith3 Philosopher ['A'..] forks (last forks : forks)

    Cette fonction est très concise mais complexe. Nous avons une liste de fourchettes (pour simplifier [fork0, fork1, fork2]) et nous voulons crée une liste de Philosophes chacun associé à une lettre et à deux fourchettes.

    On aimerait la liste suivante : [Philosopher 'A' fork0 fork2, Philosopher 'B' fork1 fork0, Philosopher 'C' fork2 fork1].

    Un motif apparaît, on voit qu'il s'agit de la fonction Philosopher appliquée à 3 arguments pris respectivement dans 3 listes distinctes grace à la fonction zipWith3 :

    • ['A', 'B', 'C'], que nous représentons ici avec la liste infinie ['A' .. ]
    • [fork0, fork1, fork2], c'est tout simplement forks
    • [fork2, fork0, fork1], qui est ici (last forks : forks)

    Cela fonctionne car zipWith3 ne consomme qu'en fonction de la longueur de la liste la plus courte.

    Vie d'un philosophe

    Une étape de la vie d'un philosophe est une fonction assez longue, mais peu complexe. La prise et la relâche des fourchettes est réalisée dans un bloc atomically, le reste n’étant que des attentes et un peu d'affichage.

    -- | Un `Philosopher` essaye de manger.
    runPhilosopher :: Philosopher -> IO ()
    runPhilosopher (Philosopher name forkA forkB) = do
      -- Prends les fourchettes de façon atomique, garantie par STM
      atomically $ do
        takeFork forkA
        takeFork forkB
    
      -- Affiche son nom en majuscules
      putChar name
    
      -- Mange pendant un temps aléatoire compris entre 0 et 2 secondes
      time <- randomRIO (0, 2 * 1000 * 1000)
      threadDelay time
    
      -- Affiche la fin du repas (nom en minuscule)
      putChar (toLower name)
    
      -- Repose les fourchettes de façon atomique
      atomically $ do
        releaseFork forkA
        releaseFork forkB
    
      -- Attend avant de recommencer pendant 100 ms
      threadDelay (1000 * 100)

    forkPhilosopher

    Cette fonction, pour un philosophe donné p, crée un green thread qui exécute en boucle infinie grâce à forever une étape de la vie de notre philosophe.

    forkPhilosopher :: Philosopher -> IO ThreadId
    forkPhilosopher p = forkIO (forever (runPhilosopher p))

    main

    Le main contient un peu de logique pour lire la ligne de commande et crée les philosophes.

    main :: IO ()
    main = do
      -- Lit le nombre de philosophe sur la ligne de commande
      nPhilosopher <- getRecord "Philosopher"
    
      -- Crée les fourchettes et les philosophes
      forks <- mkForks nPhilosopher
      let philosophers = mkPhilosophers forks
    
      -- Crée les threads par philosophe
      tIds <- mapM forkPhilosopher philosophers
    
      -- Attend 10 secondes et tue les threads
      threadDelay (1000 * 1000 * 10)
      mapM_ killThread tIds

    Quelques points à discuter dans cette fonction main. En premier lieu j'utilise getRecord pour lire la ligne de commande. Cette fonction, du module optparse-generic, est capable de créer toute seule une interface ligne de commande en fonction du type de retour demandé, ici un Int, en gérant automatiquement la lecture de la ligne de commande, la validation des arguments et l'affichage de l'aide si nécessaire. Cela m'a économisé 3 lignes de logique pour lire les arguments, vérifier qu'il y en avait au moins un, et le convertir en Int et afficher une erreur le cas échéant. Ce n'était pas forcement nécessaire dans ce contexte, mais cela devient extraordinaire avec une interface plus complexe impliquant des arguments optionnels, des drapeaux booléens, ou autres.

    La création des fourchettes est une opération avec effets de bord, d'où l'affectation du résultat avec <-. La création des philosophes elle ne réalise pas d'effet de bord, c'est une fonction pure, d'où l’égalité = qui signifie réellement que philosophers est sémantiquement équivalent à mkPhilosopher forks dans les lignes qui suivent. C'est un outil de compréhension de code que je trouve plaisant.

    Pour finir, la création des threads se fait avec mapM qui va applique la fonction forkPhilosopher à chaque philosophe et renvoyer l'identifiant du thread crée.

    Conclusion

    GHC 8.2 c'est sympa, il y a pleins de nouvelles fonctionnalités qui rendent heureux un développeur Haskell régulier. Mais soyons réaliste, ce n'est pas ces nouvelles fonctionnalités qui vont vous motiver à utiliser Haskell, c'est pourquoi j'ai essayé de présenter un cas concret d'utilisation du langage sur un problème assez classique d'algorithmie.

    Lire les commentaires

  • Wazo, le fork de XiVO, prend son envol (Dépêches LinuxFR)

    La distribution de téléphonie sur IP (PABX/IPBX) basée sur Debian et Asterisk nommée XiVO a souffert d’une soudaine extinction de voix : le site Web xivo.io et le projet GitHub ont été fermés récemment par la société Avencall. Celle‐ci détient toujours la marque XiVO et réside maintenant sous le nom de domaine xivo.solutions. (NdM.: voir ce commentaire de avencall : les sources de XiVO sont désormais sur un projet Gitlab et une version est à venir pour la fin d'année).

    Un divergeance (fork) du projet a été créée sous le nom de Wazo et les sources sont de nouveau disponibles sur GitHub. Un groupe de cinq développeurs, dont Sylvain Boily (l’initiateur du projet XiVO en 2005) a repris la gestion du nouveau projet.

    Wazo a sorti sa première version Wazo 16.16 en décembre 2016, basée sur XiVO 16.13. Vous pouvez télécharger l’image ISO sur le miroir de Wazo et une procédure de migration XiVO vers Wazo est disponible.

    Ça mange quoi en hiver, Wazo ?

    Wazo est donc un serveur de téléphonie IP basé sur Asterisk diffusé sous licence GPL v3. Il permet de gérer la téléphonie d’une entreprise avec les appels entrants, appels sortants, renvois d’appel, messageries vocales, chambres de conférence, un centre de contact modeste, de contrôler ses appels à partir de son ordinateur (CTI) et offre nombre d’API REST pour intégrer tout ce petit monde dans d’autres systèmes logiciels. À travers ces API, Wazo se veut une plate‐forme de téléphonie que vous pouvez vous approprier et autour de laquelle vous pouvez développer.

    Pourquoi le nom Wazo ?

    Wazo est tout simplement un homophone de « oiseau », principalement à cause de la mythologie du phœnix, de la renaissance d’un projet et la symbolique de prendre son envol. Pour cette raison, le projet se nomme Wazo et son nom de version pour 2017 est Phoenix. Les développeurs signalent que tout jeu de mot est le bienvenu.

    Pourquoi un fork hostile ?

    La raison principale est une divergence de vision à long terme, les développeurs de Wazo expliquent la leur :

    Nous croyons fermement que la téléphonie devrait être accessible partout : quels que soient l’appareil, l’application, l’environnement logiciel que vous avez, vous devriez pouvoir appeler qui vous voulez, quand vous voulez. Pour accomplir cela, nous voulons un logiciel de téléphonie qui soit facile à mettre en place, facile à intégrer à d’autres logiciels, scalable et extensible à volonté.

    Wazo 16.16, nouvelle version, qu’est‐ce qu'elle apporte ?

    La nouvelle version de Wazo est arrivée lundi 12 décembre 2016, et elle apporte quelques nouveautés :

    • la migration de XiVO vers Wazo ;
    • la prise en charge du codec Opus ;
    • une meilleure documentation des API REST ;
    • une nouvelle API REST pour les interconnexions SIP avec les opérateurs et la gestion d’appels sortants ;
    • une nouvelle API REST pour les groupements d’appels (plusieurs téléphones sonnent sur le même numéro) ;
    • une nouvelle API REST pour les chambres de conférence ;
    • une nouvelle API REST pour les menus vocaux ;
    • une nouvelle API REST pour les messages vocaux utilisateur ;
    • une gestion plus souple du carnet d’adresses ;
    • amélioration de l’interconnexion de plusieurs serveurs Wazo pour partager les contacts.

    Wazo en 2017, quel plan de vol ?

    Pour l’année 2017, l’équipe prévoit notamment :

    • d’ajouter une nouvelle interface Web d’administration, plus moderne et plus facilement extensible ;
    • de continuer le développement des API REST pour piloter l’intégralité du projet ;
    • de fournir des interfaces web et mobile pour les utilisateurs ;
    • de continuer son approche scalable pour une vision Cloud (PaaS ou SaaS) ;
    • et, bien sûr, d’être à l’écoute de la communauté et de répondre à ses préoccupations premières.

    Comment on finance les graines ?

    Comme tout projet logiciel, il faut bien sûr financer le temps de développement et l’équipe nous fait savoir qu’ils ont plusieurs idées dans les cartons. Ils souhaitent rentabiliser un modèle logiciel libre en fournissant du service, du développement, mais aussi apporter une nouvelle approche sur le modèle de commercialisation, sans utiliser les mécanismes retrouvés actuellement dans des projets à double licence. Donc, pas de fonctionnalités payantes à l’horizon, comme ce qui fait grincer du bec chez les utilisateurs de FreePBX ou Elastix, d’autres projets libres de téléphonie sur IP…

    Lire les commentaires

  • Livre O'Reilly en téléchargement gratuit légal (Journaux LinuxFR)

    Journal bookmark : O'Reilly propose de télécharger gratuitement une centaine d'ouvrages, de tous domaines : IoT, Sécurité, Programmation, Management…

    C'est par ici : http://www.oreilly.com/free/reports.html

    Lire les commentaires

  • Intégration du rendu français d'OpenStreetMap dans KDE Marble (Journaux LinuxFR)

    Bonjour,

    La communauté française d'OpenstreetMap a réalisé un rendu très pratique pour les francophones :
    http://tile.openstreetmap.fr/

    Notamment on y trouve les traductions en Français des noms étrangers, des icônes adaptées (la Poste, SNCF, etc.) et une gestion du zoom mieux adaptée que sur le rendu par défaut.

    Perso je l'utilise pas mal avec le globe virtuel Marble, de KDE. Il s'agit d'un logiciel pour naviguer sur des cartes, assez pratique et moins consommateur en ressource puisqu'il garde un cache local des tuiles, au lieu de les télécharger à chaque fois.

    C'est assez utile par exemple suivre l'actualité: situer la fameuse usine Lafarge-Holcim en Syrie, la ZAD de Notre-Dames des Landes ou encore la Corée du Nord…

    Il y a quelques années j'avais fait une intégration de OSM-FR dans marble, j'ai enfin trouvé la motivation pour le mettre sur github:
    https://github.com/adrien-github/osmfr

    Je me suis dit que ça pouvait peut-être intéresser des gens ici.

    Lire les commentaires

  • Transformez votre Raspberry Pi en télécommande infrarouge (Dépêches LinuxFR)

    ANAVI Infrared pHAT est une carte fille pour Raspberry Pi avec tout ce qu’il faut pour faire une télécommande infrarouge en émission et réception, et donc virtuellement tout contrôler via LIRC, mais aussi faire mumuse avec des capteurs I²C (température, pression, etc.) en option. Le prix de vente est en dessous des 10 € symboliques, via la plate‐forme de cofinancement IndieGoGo.
    En d’autres termes, voici le kit idéal pour contrôler ses appareils domestiques (TV, Hi‐Fi, clim, etc.) et les rendre un peu plus « smarts », tout en restant libre.

    IR pHAT

    Côté logiciel, rien de magique, tout est documenté (en anglais, mais je peux vous aider car j’ai un proto sous la main).

    Peut‐être vous souvenez‐vous de l’annonce de la carte fille Rabbit Max Flex annoncée fin 2016 sur LinuxFr.org ? Eh bien, il s’agit du même auteur, Leon Anavi, qui a été contraint d’abandonner le nom rabbit (car certains en revendiquent la propriété) et a rebaptisé le projet par son nom propre pour éviter tout problème légal. Les deux cartes ont été réalisées à l’aide de KiCad et les sources sont disponibles, car l’auteur est motivé par la communauté OSHW et FLOSS, plus de détails dans cette présentation au FOSDEM (en anglais).

    Notez que la campagne est déjà financée à plus de 1 000 %, il n’y a donc pas de souci pour la réalisation. La livraison est estimée courant été 2017.

    Le tout est fait avec amour et dans la communauté européenne (Plovdiv, en Bulgarie, la plus ancienne ville d’Europe encore peuplée).

    Lire les commentaires

  • Swift sous GNU/Linux - Introduction (Dépêches LinuxFR)

    Swift est le nouveau langage de programmation d’Apple. Il a été rendu libre et open-source, sous licence Apache 2.0, le 3 décembre 2015. Nous allons voir à travers cet article comment l’installer et l’utiliser sur GNU/Linux. Vous n’avez pas besoin d’avoir de connaissance avancée de GNU/Linux, ni de machine avec GNU/Linux installée pour suivre ce tutoriel.

    Swift

    Sommaire

    Installation de Swift sur GNU/Linux

    Si vous avez déjà Ubuntu 14.04 LTS ou Ubuntu 15.10, en machine physique ou virtuelle, vous pouvez simplement suivre les instructions sur le site swift.org pour télécharger et installer Swift pour Linux. Vous pouvez alors vous rendre directement à la section suivante.

    La suite vous décrit les étapes pour installer simplement une machine virtuelle Ubuntu dotée du nouveau langage Swift.

    Installation de VirtualBox

    VirtualBox est un logiciel libre vous permettant de configurer et faire tourner des machines virtuelles. Si ce n’est déjà fait, installez-le en vous rendant à la page de téléchargement du site.

    Installation de Vagrant

    Vagrant est un logiciel en ligne de commande qui permet d’installer et configurer des machines virtuelles à l’aide de scripts. Rendez-vous à la page de téléchargement du site, téléchargez et lancez l’installeur du système d’exploitation de votre machine hôte.

    À l’aide du script suivant, vous allez pouvoir télécharger et configurer votre machine virtuelle en une ligne de commande !

    Créez un dossier vagrant-swift, puis créez dans ce dossier, un fichier nommé Vagrantfile contenant le code suivant :

    Vagrant.configure(2) do |config|
      config.vm.box = "ubuntu/trusty64"
      config.vm.provision "shell", inline: <<-SHELL
        sudo apt-get --assume-yes install clang
        curl -O https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
        tar zxf swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
        echo "export PATH=/home/vagrant/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin:\"${PATH}\"" >> .profile
        echo "Swift has successfully installed on Linux"
      SHELL
    end

    Pour les utilisateurs Windows, il vous faudra un terminal qui permet d’exécuter des commandes Unix. Je vous recommande Git Bash de la suite Git for Windows. Durant l’installation, vous pouvez laisser toutes les options de configuration par défaut. Une fois installée, vous devez lancer Git Bash.

    Ouvrez un terminal si ce n’est déjà fait (Git Bash si vous êtes sous Windows). Placez-vous dans le répertoire vagrant-swift et lancez la commande suivante :

    $ vagrant up

    Allez boire une bière le temps que Vagrant procède aux étapes suivantes :

    Téléchargement d’Ubuntu 14.04 LTS
    Lancement de la machine virtuelle
    Installation du compilateur clang
    Téléchargement et décompression de Swift
    Configuration de la variable PATH de l’utilisateur

    Vous aurez peut-être des messages affichés en rouge, vous pouvez les ignorer. Si tout s’est déroulé correctement, le dernier message indique :

    ==> default: Swift has successfully installed on Linux
    La machine virtuelle est prête, connectez-vous en ssh en lançant cette commande :

    $ vagrant ssh

    La connexion établie, vous obtenez un prompt de ligne de commande :

    vagrant@vagrant-ubuntu-trusty-64~$

    Vérifiez que Swift est bien installé en tapant :

    vagrant@vagrant-ubuntu-trusty-64:~$ swift --version
    Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c)  
    Target: x86_64-unknown-linux-gnu

    Premier programme

    Live

    Les développeurs iOS ou OS X le savent déjà grâce au playground d’Xcode, Swift est un langage pouvant être exécuté en live grâce au REPL (Read-Eval-Print-Loop).
    Lancez la commande swift, un prompt apparaît, entrez alors votre première ligne de code Swift sur Linux !

    vagrant@vagrant-ubuntu-trusty-64:~$ swift
    Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
    1> print("Hello, Swift!")
    Hello, Swift!
    2>

    Pour quitter votre session Swift REPL, entrez la commande :q.

    Compiler un programme

    Pour compiler un programme écrit en Swift, créez un fichier source, par exemple de la manière suivante :

    $ cat > helloworld.swift

    Puis rentrez cette unique ligne de code :

    print("Hello World !")

    Appuyez une fois sur Entrée suivi de CTRL-D pour créer le fichier. Listez le répertoire courant pour vous assurer de la présence du fichier fraîchement créé en tapant la commande ls. Compilez maintenant votre programme en tapant :

    $ swiftc helloworld.swift

    Si vous listez le répertoire courant, vous verrez qu’un nouveau fichier exécutable nommé helloworld a été créé. Votre programme est prêt à être lancé, tapez :

    $ ./helloworld

    Vous devriez voir en sortie :

    Hello World !

    Ce qu’Apple a rendu open source

    Seulement une partie de la technologie est disponible en open source pour le moment. Les composants sont :

    • Compilateur Swift, sources et exécutables, débogueur, REPL. C’est le coeur du langage lui-même. Apple a rendu open les sources du programme swiftc, le même compilateur utilisé pour compiler les applications iOS et OS X.
    • Bibliothèque standard Swift. Presque la même bibliothèque standard utilisée depuis la sortie de Swift, elle comprend la définition des collections, protocoles et autres fondamentaux. Si par curiosité, vous voulez voir comment est définie la classe (plus précisément la structure) String, rendez-vous sur le github ici.
    • Bibliothèques Swift core. Elles font peau neuve aux bibliothèques existantes d’Apple écrites en Objective-C. Elles fournissent des fonctionnalités et des outils de haut niveau tels que ceux pour la communication web, l’interaction avec le système de fichiers, les calculs de date et heure.
    • Swift Package Manager. C’est le maître de cérémonie de l’assemblage de chaque brique qui forme une application. Il va télécharger les dépendances, les compiler et les lier entre-elles pour créer des bibilothèques ou des exécutables.
    • Mais encore… Si vous parcourez la page Github d’Apple, vous trouverez d’autres composants tels qu’une encapsulation de libdispatch (Grand Central Dispatch), des informations sur Swift 3.0, ou même un parseur du langage Markdown…

    Ce qui n’est pas (encore) disponible

    Il manque à l’appel la plupart des frameworks qui rendent les applications iOS et OS X aussi belles. Pour n’en citer que quelques-uns : AppKit, UIKit, Core Graphics, Core Animation, AVFoundation…

    Vous ne trouverez pas non plus l’environnement de développement intégré Xcode.

    Mais ce qu’Apple a rendu open source est plutôt significatif. En effet, le fait que les bibliothèques Swift Core ne reposent plus sur l’environnement d’exécution Objective-C montre qu’Apple est en train de créer les fondements de Swift pour, à long terme, remplacer Objective-C. De plus, le fait que Swift soit cross-platform suggère qu’Apple espère voir les développeurs l’utiliser pour le développement d’applications Linux entre autres. Si ce n’est pour des applications GUI, au moins pour des applications serveurs.

    Swift Package Manager

    Voyons en pratique l’utilisation du package manager sur un exemple simple, un petit jeu de « pierre, feuille, ciseaux ». Créez un dossier helloswift puis un dossier sources à l’intérieur du premier en exécutant les commandes suivantes :

    $ mkdir helloswift  
    $ cd helloswift  
    $ mkdir sources  
    $ cd sources

    Créez ensuite un fichier nommé main.swift, (le nom main est important pour la suite), dans le répertoire sources en exécutant :

    $ cat > main.swift
    

    Copiez le programme suivant :

    import Foundation
    import Glibc
    
    let player = ["pierre", "feuille", "ciseaux"]
    
    srandom(UInt32(NSDate().timeIntervalSince1970)) 
    
    for count in 1...3 {
        print(count)
        sleep(1)
    }
    
    print(player[random() % player.count]);

    Tapez Entrée puis CTRL-D.

    Vous pouvez d’ores et déjà exécuter votre programme avec la commande :

    $ swift main.swift
      Génial ! Il faut que j’en parle aux copains !
    Arf… il n’auront pas la commande swift…
    

    C’est ici que le Swift Package Manager entre en jeu ! Grâce à lui, vous allez pouvoir distribuer un exécutable de ce formidable programme. Créez un fichier Package.swift dans le dossier parent (helloswift) :

    $ cd ..
    $ cat > Package.swift

    Copiez ceci dedans puis tapez Entrée et enfin CTRL-D :

    import PackageDescription
    
    let package = Package(
        name: "Chifoumi"
    )

    Lancez la commande de build :

    $ swift build

    Swift détecte automatiquement le point d’entrée du programme car nous avons nommé notre fichier main.swift. Si vous renommez ce fichier, vous aurez des erreurs de compilation. En revanche le changement de nom du dossier sources n’affecte pas la compilation mais l’exécutable créé portera le nom du dossier et non le nom donné dans le fichier Package.swift. Si la compilation réussit, le package manager crée un dossier .build contenant un dossier debug dans lequel se trouve l’exécutable Chifoumi. Vous pouvez alors le distribuer et quiconque ayant une machine Linux pourra l’exécuter en tapant la commande suivante dans le répertoire où se trouve l’exécutable :

    $ cd .build/debug/
    $ ./Chifoumi

    Le Swift package manager possède évidemment beaucoup de fonctionnalités que nous n’avons pas explorées. Un guide d’utilisation plus avancée fera peut-être l’objet d’un nouvel article, qui sait ?

    Stay tuned !

    Références / Sources

    Lire les commentaires

  • Minage en douce (Journaux LinuxFR)

    On commence à voir fleurir les codes qui minent en douce, par exemple dans
    https://addons.mozilla.org/fr/firefox/addon/free-download-manager/
    https://www.virustotal.com/#/file/89e1c233d43d23422336c9cb8e670c848b50d62ae020bb50d6a3a5795b000fc9/detection
    Avant, il n'y avait que les ordinateurs sous Windows qui ramaient, maintenant, tous les systèmes seront au même régime.

    Lire les commentaires

  • Des sonneries de téléphone en morse (Journaux LinuxFR)

    Vous avez envie de vraies sonneries de mobile personnalisées ?

    Faites les en morse !

    « Tata tita tata tita tati », ça sonne mieux que « maman » non ?

    Ça tient en deux programmes :

    • txt2mrs qui convertit du texte en code morse,
    • mrs2snd qui convertit du code morse en fichier wav.

    On peut les trouver là : https://framagit.org/mabu/txt2snd/

    En C, la seul dépendance est libsndfile, donc ça devrait se compiler sur une majorité de système.

    Lire les commentaires

  • Campagne de financement d’eelo pour un smartphone respectueux de la vie privée (Dépêches LinuxFR)

    Gaël Duval, le créateur de la distribution Mandrake Linux, a décidé de se lancer dans un nouveau combat : créer un système d’exploitation pour smartphone / ordinateur de poche qui soit respectueux de la vie privée, libre et utilisable par le commun des mortels. Ce projet nommé eelo est à but non lucratif, dans l’intérêt du public.

    Logo d’eelo

    Autre logo

    Mais pour avancer et atteindre une taille critique suffisante pour maintenir un système d’exploitation, il y a besoin de pouvoir payer des développeurs et donc de financer tout ça. Gaël Duval a décidé de faire appel à un financement participatif pour atteindre un premier produit utilisable en partant de LineageOS. Il espère pouvoir ensuite attirer des contributeurs et itérer sur de nouvelles versions.

    Depuis quelques semaines, la petite équipe (Gaël Duval, un développeur expérimenté Hathibelagal Ashraff et un designer Rhandros Dembicky) a déjà réalisé tests et preuves de concepts. Gaël souhaite mettre l’accent sur la facilité d’utilisation pour que le commun des mortels n’ait aucun mal à se passer des GAFAM. Ce qu’on traduit par trouver les bonnes alternatives et soigner les détails d’interface.
    Par exemple, déçus par l’existant, ils ont choisi d’écrire un lanceur d’applications et un système de notifications plus ergonomiques. Ça marche et c’est déjà beaucoup mieux. Ils ont compilé des ROM en intégrant OnlyOffice, NextCloud, Telegram, etc., afin de tester au quotidien.

    NdM. : Un homonyme à ne pas confondre, « entrepreneur français du secteur de l’Internet » (source) est aussi dans l’actualité française pour un tout autre sujet, en tant que membre démissionnaire du Conseil National du Numérique (CNNum).

    Lire les commentaires

  • Cartographie et images de rues : Mapillary et OpenStreetCam (Dépêches LinuxFR)

    Vous connaissez probablement déjà OpenStreetMap, la base de données cartographique libre. Mais vous connaissez sans doute aussi des concurrents qui proposent en plus des cartes d’autres services, comme les images aériennes, et depuis une dizaine d’années vous avez peut‐être pris l’habitude des images prises directement dans les rues : StreetView chez Google, StreetSide chez Microsoft…

    Des alternatives libres se mettent en place, et c’est ce dont nous allons parler : OpenStreetCam, né en 2013, et Mapillary. Les deux initiatives sont ouvertes, tout le monde peut participer facilement via une application pour mobile.

    Ces solutions permettent une alternative libre pour les utilisateurs et sont une aide très précieuse pour les contributeurs d’OpenStreetMap.

    Sommaire

    Réunir une telle collection d’images aurait pu paraître impossible il y a peu, mais l’avènement des smartphones change la donne : cartographier une rue peut être aussi simple que de fixer son téléphone sur son vélo, sa voiture, ou le tenir à la main en marchant. Une application s’occupe de prendre des photos (géolocalisées, bien sûr) périodiquement et de les envoyer vers les serveurs qui s’occupent du reste.

    Dur d’atteindre la qualité des images panoramiques à 360° des concurrents, mais, à l’inverse, permettre à tout le monde de contribuer permet aussi de couvrir les zones inaccessibles en voiture.

    En cinq ans, Mapillary a collecté 179 millions d’images (après avoir passé les 100 millions il y a moins d’un an), soit plus de trois millions de kilomètres couverts. La couverture OpenStreetCam n’est pas encore aussi bonne, mais c’est quand même plus de 50 millions d’images, et la croissance est très forte de ce côté aussi (multiplication par quatre depuis novembre 2016).

    À quoi tout ceci peut‐il servir ?

    • Pour tout le monde : comme la concurrence, à savoir à quoi ressemble un endroit sans y être allé, à planifier un itinéraire… On peut accéder aux images depuis un navigateur via le site des deux projets. Mapillary est intégré à l’application libre Android OsmAnd depuis la version 2.7 de juillet 2017 (disponible sur le dépôt F-Droid sous le nom OsmAnd~). On peut maintenant visualiser les séquences Mapillary directement sur la carte :

    Mapillary dans OsmAnd : séquences visibles sur la carte

    Ou plus simplement, une section « photos en ligne » est maintenant disponible quand on examine les détails d’un lieu :

    Mapillary dans OsmAnd : photos des lieux

    • Pour les contributeurs OpenStreetMap, c’est un outil précieux pour la cartographie de fauteuil, c’est‐à‐dire la possibilité d’éditer la carte OpenStreetMap sans être sur le lieu qu’on édite et éventuellement sans avoir fait de reconnaissance au préalable. L’éditeur ID en ligne sur https://openstreetmap.org permettait déjà d’éditer sur fond d’images aériennes ou de plan de cadastre par exemple. On peut maintenant visualiser les images de Mapillary directement depuis l’éditeur et, mieux encore, voir directement les panneaux de signalisation détectés par Mapillary en analysant les images.

    Mapillary

    Le principe de Mapillary est de récolter puis d’analyser un maximum d’images. L’analyse d’image permet de repérer les panneaux, feux tricolores, et aussi d’autres éléments comme les voitures, garages à vélo, verdure, poubelles… Ces données sont utilisables librement par OpenStreetMap, et l’entreprise derrière Mapillary monnaye ces données.

    Voici par exemple ce que Mapillary détecte place du Trocadéro :
    Données détectées place du Trocadéro

    Ces données sont utilisables directement depuis les éditeurs OpenStreetMap ID (éditeur par défaut depuis le site Web) et JOSM (client lourd). Lire l’article de blog et les vidéos associées pour les détails. Les éléments de carte peuvent être associés à une image Mapillary via l’étiquette mapillary=….

    Mapillary est également intégré dans l’application Android OsmAnd.

    OpenStreetCam

    OpenStreetCam est mené par Telenav, qui s’appuie sur OpenStreetMap pour les outils de navigation qu’elle commercialise.
    OpenStreetCam en ligne

    Une originalité d’OpenStreetCam est sa manière d’encourager les contributeurs par un système de points : on gagne des points en contribuant des images, et d’autant plus de points qu’on couvre des zones non couvertes.

    OpenStreetCam est intégré dans l’éditeur JOSM, mais pas (encore ?) dans ID ni OsmAnd.

    Historiquement, le projet s’est lancé sous le nom OpenStreetView pour reprendre le nom de domaine d’un projet lancé en 2009 qui n’avait pas réussi à devenir populaire. Il a été renommé plus tard en OpenStreetCam pour éviter la confusion possible avec la solution de Google.

    Est‐ce vraiment libre ?

    On lit çà et là sur le Web des controverses comme quoi l’une des solutions est commerciale et l’autre libre. En réalité, les deux solutions sont supportées par des entités commerciales (Mapillary AB est une entreprise basée en Suède centrée sur le service mapillary.com, et OpenStreetCam est mené par l’entreprise Telenav qui vend des systèmes de navigation pour voiture qui utilisent OpenStreetMap). Et les deux solutions sont « en grande partie libre ».

    Les deux services distribuent les images sous licence CC-BY-SA, et dans les deux cas les contributeurs donnent au service une licence qui lui permet d’utiliser les images sans restrictions.

    Chez OpenStreetCam, le code du site Web et des applications pour Android et pour iOS sont libres (mais au moins l’application Android a des dépendances non libres qui empêchent, entre autres, son inclusion dans F-Droid). Mapillary fournit plusieurs logiciels libres, par exemple mapillary-js, le code qui permet l’affichage des images sur leur site Web, mais l’application pour Android et iOS n’est pas libre (elle pourrait le devenir prochainement).

    Pour Mapillary, il faut distinguer les conditions d’utilisation du service et la licence des images. Les conditions pour le service ne permettent pas l’usage commercial hors contrat avec lui (d’après la partie 1.2 de ses conditions d’utilisations) et limitent par défaut les téléchargements à 50 000. La licence des images est la licence CC-by-SA et il est possible de re‐licencier les travaux dérivés dans le cadre d’OpenStreetMap selon les conditions de la fondation OpenStreetMap. En d’autres termes, il y a des restrictions sur le téléchargement d’images, mais une fois les images téléchargées, elles sont utilisables librement. Les images sont libres, mais le service n’est pas entièrement gratuit (250 €/mois pour le pack « professional », par exemple).

    Pour un comparatif des conditions des deux services (écrite par un employé Mapillary), voir par exemple ici.

    Et la pérennité ?

    L’ouverture est souvent citée comme gage de pérennité. Si l’auteur d’un logiciel libre décide de passer à autre chose, quelqu’un d’autre peut, au moins en théorie, prendre le relai.

    Pour OpenStreetCam et Mapillary, la situation est un peu plus compliquée. Le scénario catastrophe où l’un des deux arrête son activité ou se fait racheter par une entreprise qui décide d’arrêter de diffuser les images sous licence libre est tout à fait possible. Pour qu’une autre entité puisse reprendre la suite, il faut que deux conditions soient réunies : que les images soient réutilisables (c’est le cas avec la licence CC-BY-SA), et que quelqu’un ait gardé les images avant qu’elles ne disparaissent. C’est le deuxième point qui est problématique : les bases d’images sont colossales (plus de 500 téraoctets pour Mapillary, un peu moins pour OpenStreetCam, mais fort taux de croissance dans les deux cas) donc maintenir un stockage correctement fiabilisé pour un miroir aurait un coût de l’ordre de la centaine de milliers d’euros par an (en calcul de coin de table…). Ajouté à la limite de téléchargement pour Mapillary, maintenir un miroir n’est clairement pas à la porté du premier venu (même si en comparaison une fondation comme celle de Wikipédia gère un budget autrement plus élevé). Côté OpenStreetCam, certains en ont discuté, mais toujours pas de miroir non plus.

    On peut espérer que les deux services ne fermeront pas en même temps, donc une solution pour les contributeurs pour pérenniser leurs images est d’envoyer les images aux deux, mais ce n’est pas faisable directement depuis les applications pour mobile. Certains contributeurs conservent également une copie de leurs images localement, « au cas où ».

    Comment contribuer ?

    Contribuer est très facile si vous avez un smartphone. Un contributeur peut installer l’application et prendre des images de sa rue à pied et sans matériel supplémentaire en quelques minutes, ou se fixer des objectifs plus ambitieux comme certains contributeurs qui s’imposent de dépasser le million d’images contribuées en un mois. Pour contribuer en voiture ou à vélo, il est recommandé d’avoir un support, Mapillary en envoie gratuitement sur demande aux contributeurs si besoin. Toute la richesse de ces bases d’images vient de la diversité des contributeurs, donc de la diversité des images qu’elles contiennent.

    Alors, vous avez commencé ? Qu’attendez‐vous ? ;-)

    Lire les commentaires

  • Migration de / d'un disque dur à l'autre avec btrfs (Journaux LinuxFR)

    Bonjour,

    Suite aux bons journaux trouvés sur linuxfr à propos de btrfs,
    j'ai transformé mes systèmes de fichier principaux en btrfs pour pouvoir
    bénéficier de ses avantages et de snapperd.

    Aujourd'hui, j'ai fait une mise à jour de mon nas pour passer du ssd au nvme.

    Le nouveau disque est plus petit que l'ancien, je ne peux pas faire une bête
    copie bit à bit de l'ancien disque vers le nouveau comme je fais à mon habitude.

    Au vu des quelques sous-volumes que j'ai (69), il est hors de question aussi
    que je recréé l'arborescence des sous-volumes et que je fasse des copies.

    Du coup, j'ai eu l'idée d'étendre le système de fichier avec le nouveau disque, puis
    de retirer l'ancien.

    Voilà ce que ça donne sur la ligne de commande:

    [root:~] # # Nombre de sous-volumes
    [root:~] # btrfs sub list / |wc
         69     621    4447
    [root:~] # # Taille du volume btrfs avant:
    [root:~] # df -h /
    Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
    /dev/sdd2          476G    103G  373G  22% /
    [root:~] # # ajout du nouveau disque
    [root:~] # btrfs device add /dev/nvme0n1 /
    Performing full device TRIM /dev/nvme0n1 (232.89GiB) ...
    [root:~] # # Nouvelle taille intermédiaire
    [root:~] # df -h /
    Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
    /dev/sdd2          709G    103G  606G  15% /
    [root:~] # # suppression de l'ancien disque
    [root:~] # btrfs device delete /dev/sdd2 /
    [root:~] 2h16m58s #
    

    Et tout ça à chaud sans avoir besoin d'arrêter le système, sauf pour retirer l'ancien disque.

    Le seul bémol que je trouve à utiliser btrfs c'est que les opérations
    peuvent être lentes parfois. Ici, j'ai déplacé 103Go en 2h16, soit du 12Mo/s …

    Heureusement que c'est du ssd !

    Je n'ai pas trouvé non plus comment voir la progression de l'opération 'device delete'.
    J'aurais peut-être dû utiliser la commande 'balance' pour pouvoir voir la progression en
    temps réel.

    Btrfs, c'est bon ! mangez-en ;)

    Lire les commentaires