Linux (fr)

  • Sortie de Tryton 3.4 (Dépêches LinuxFR)

    Comme à l'accoutumée, le mois d'octobre voit la sortie d'une nouvelle version de Tryton, la plate-forme de développement d'applications pour entreprise (progiciel de gestion intégré ou PGI mais aussi ERP).

    Tryton

    Sur cette version, un gros travail a porté sur la partie comptabilité, mais aussi sur une multitude de petites améliorations pour simplifier la vie des développeurs de modules.

    Et, bien évidement, la migration depuis les précédentes versions est assurée.

    Vous pouvez venir découvrir toutes ces nouveautés à la conférence annuelle de la communauté qui se déroule cette année à Leipzig.

    Détails des nouveautés

    Interface utilisateur

    Les widgets des champs relations ont été retravaillés pour tirer avantage de l'auto-complétion en les simplifiant. Les boutons ont été remplacés par une icône dans le champs qui permet soit de rechercher, soit d'ouvrir le contenu.

    Une prévalidation côté client a été ajoutée. Elle permet un meilleur retour à l'utilisateur par rapport à un message d'erreur. En effet, le client est capable de mettre en surbrillance les champs non valides.

    Un complètement automatique entre le code postal et la ville est disponible sur les adresses. Les données de GeoNames peuvent être chargées dans la base de données via un script.

    La fenêtre d'export d'enregistrement a été retravaillée afin de fournir une meilleur expérience à l'utilisateur. Elle s'ouvre avec les champs de la vue courante pré-sélectionés. Il est possible de modifier et de sauvegarder directement un export prédéfini. L'ordre des champs peut aussi être changé par glisser-déposer.

    Outils pour développeur

    Le patron commun dans Tryton de rechercher un enregistrement dans une liste suivant des critères sur des valeurs (de manière modulaire) a été généralisé dans un Mixin.

    Un autre Mixin a ausi été ajouté, permettant de définir un nouveau modèle (objet) comme étant l'UNION (l'opérateur SQL) de plusieurs modèles.

    Un descripteur a été ajouté aux champs de sélection, il permet d’accéder aux labels de ceux-ci au lieu de leurs valeurs internes.

    Le fichier de configuration est maintenant extensible à volonté et donc il peut être utiliser pour le paramètrage des modules. C'est déjà le cas du module ldap_authentication qui va y chercher les paramètres de configuration du serveur LDAP.

    Proteus (la bibliothèque pour accéder à Tryton comme le client) est maintenant capable d’exécuter les rapports. Et une méthode duplicate voit le jour qui imite la fonctionnalité de copie d'enregistrement du client.

    Sécurité

    Les droits d'accès ont été revus pour n'être appliqués que sur les appels RPC. Ceci simplifie grandement le développement, vu que les droits d'accès ne sont contrôlés qu'aux bordures du système et donc le développeur n'a plus à devoir basculer en utilisateur root pour effectuer certaines opérations.

    Comptabilité

    Un nouvel assistant de lettrage comptable fait son entrée. Il passe en revue tous les comptes et tiers qui contiennent des lignes à lettrer et fait une proposition de combinaison. L'utilisateur peut l'accepter tel quelle ou bien la modifier, ainsi que passer une partie en pertes et profits. Ce mode de fonctionnement accélère grandement cette tâche comptable.

    Un autre assistant permet d'annuler rapidement une écriture comptable en passant l'écriture inverse. Une option permet de directement lettrer les entrées possibles.

    Afin de rendre plus homogène l'utilisation du champ tiers sur les écritures comptables, ce champ est rendu obligatoire ou interdit en fonction du paramétrage du compte sur lequel l'écriture est passée. Ceci permet de configurer le système pour soit fonctionner avec des comptes groupés pour les tiers ou bien avec un compte par tiers. Tous les modules ont été vérifiés pour gérer correctement les deux cas de figures automatiquement.

    Il est maintenant possible de choisir entre un arrondi des taxes « par ligne » ou « par document ». La méthode par défaut reste « par document ».

    Les lignes des relevés comptables peuvent être ordonnées et numérotées afin de correspondre au mieux à la version papier. De nouvelles méthodes de validation des extraits sont disponibles : « balance », « montant » et « nombre de ligne ».

    Il est maintenant possible de changer par année fiscale la méthode de valorisation perpétuelle du stock (« Continentale » ou « Anglo-Saxonne »).

    Les paiements

    Les paiements à l'état « réussi » peuvent maintenant être changés en « échoué ». C'est moins contraignant en cas d'erreur d'encodage.

    La prise en charge du schéma « Business to Business » de la norme SEPA pour les prélèvements automatiques a été ajoutée. Les messages de notification de débit/crédit (CAMT.054) sont gérés. Le numéro d'identification et le formulaire de mandat sont configurés par défaut.

    Un nouveau module account_payment_clearing permet de générer automatiquement un mouvement pour le paiement dans un compte d'attente de la banque. Ce mouvement sera par la suite compensé, lors de l'encodage de l'extrait de compte.

    Lire les commentaires

  • Préparation de documents LaTeX avec BSD Owl (Dépêches LinuxFR)

    À l'occasion de la sortie de BSD Owl 2.2.1 — le système de compilation portable pour BSD Make — je vous propose d'apprendre à utiliser BSD Owl pour préparer et publier vos documents LaTeX.

    Ce texte est une traduction de la page du Wiki “Producing LaTeX documents”.

    Sommaire

    Préparer des documents avec LaTeX

    Vous apprendrez dans ce texte comment utiliser les scripts BSD owl (bsdowl) pour :

    • préparer des documents simples et les publier dans l'arborescence des fichiers;
    • préparer la bibliographie de vos documents LaTeX avec BIBTeX;
    • préparer des figures pour vos documents avec METAPOST;
    • gérer des documents dont certains éléments doivent être automatiquement régénérés;
    • gérer des documents dispersés dans différents répertoires.
    • gérer des collections comportant un grand nombre de documents.

    Avertissement: travailler avec TeX ou LaTeX

    Il y a de nombreux formats TeX, plain TeX et LaTeX en sont deux exemples. Le format LaTeX jouit d'une grande popularité et nous avons choisi d'utiliser le module latex.doc.mk dans les exemples. Cependant, ce qui suit s'applique aussi au module tex.doc.mk. Certains paragraphes dans la suite identifient les mécanismes spécifiques à latex.doc.mk.

    Avertissement: BSD Make

    Ne vous trompez pas de version de make : la plupart des distributions Linux installent GNU Make comme programme make principal, la version BSD de make est souvent appelée bmake et installable via un paquet du même nom. Sous les BSD, on trouve naturellement BSD Make comme commande make. Sous Mac OS X, c'est le programme bsdmake.

    Utilisation simple

    La préparation d'un document simple avec LaTeX est en elle-même particulièrement simple, l'utilisation de bsdowl pourrait donc sembler une complication inutile. Cependant, même dans ce cas, l'utilisation de bsdowl rend d'appréciables services, comme l'installation et l'horodatage des fichiers produits.

    Néanmoins, la partie vraiment intéressante se situe dans la partie avancée.

    La première fois

    Supposons que le fichier script.tex contient notre texte et mettons-le dans un répertoire dédié. Créons un fichier Makefile (la majuscule compte) qui contient :

    DOC = script.tex
    .include "latex.doc.mk"

    de sorte que le répertoire dédié contient maintenant script.tex et ce Makefile. Rendons-nous avec un shell dans ce répertoire et tapons make:

    % make
    make build
    ===> Multipass job for script.dvi (aux)
    latex script.tex
    This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
    entering extended mode
    (./script.tex
    LaTeX2e <2003/12/01>
    ...

    S'il n'y avait pas d'erreur dans script.tex, on se retrouve avec les fichiers "compilés" suivants dans le répertoire courant :

    % ls
    Makefile    script.log
    script.aux  script.tex
    script.dvi  script.toc

    Lorsque les produits de compilation ne sont plus nécessaires, vous pouvez nettoyer le dossier de travail avec le mantra make clean:

    % make clean
    rm -f  script.dvi script.log script.aux script.toc

    Le nettoyage du dossier de travail est une étape optionnelle qui évite de voir son dossier personnel rempli de données inutiles, qui peuvent rapidement être recréées. Les fichiers DVI sont habituellement très petits, de l'ordre de quelques centaines de kilobits, mais les fichiers PostScript ou PDF sont habituellement bien plus gros.

    Installation ou publication

    Avant de nettoyer votre dossier de travail avec le mantra make clean, vous pouvez vouloir copier ce document à un emplacement approprié du système de fichiers. Cette étape s'appelle installation du document, car elle est analogue à l'installation d'un programme nouvellement compilé. Vous installez le document grâce à la commande make install mais il faut auparavant dire à make quel emplacement du système de fichiers est approprié. Il faut pour cela assigner à la variable DOCUMENTDIR le chemin du dossier où vous voulez que vos fichiers soient copiés, comme l'illustre le Makefile suivant :

    DOCUMENTDIR = ${HOME}/doc/report
    DOC = script.tex
    .include "latex.doc.mk"

    Vous pouvez alors passer à la commande make install:

    % make install
    install -d /home/michi/doc/report
    install -o michi -g michi -m 440 script.dvi /home/michi/doc/report

    En comparaison avec la copie manuelle du document produit, vous vous épargnez la saisie récurrente du dossier de destination après chaque mise à jour du document. Mais confier cette tâche élémentaire au Makefile a d'autres avantages plus importants :

    • Cela simplifie l'organisation de votre bibliothèque de sources pour vos documents.
    • Cette stratégie s'adapte à une collection importante de documents, cf. Travailler avec une collection de documents plus bas.
    • En mode brouillon, un suffixe horodatant le fichier est automatiquement ajouté, comme expliqué plus bas.

    Choix du format de sortie

    La chaîne de production TeX est capable de produire des documents électroniques dans plusieurs formats, comme DVI, PostScript (PS) ou PDF. La variable TEXDEVICE commande le choix du format de sortie des documents préparés avec latex.doc.mk. Cette valeur est généralement dvi de sorte qu'un fichier DVI sera préparé à partir du document source. D'autres valeurs possibles sont ps ou pdf. Si vous avez configuré une imprimante PostScript avec texconfig(1), disons TEXPRINTER, vous pouvez utiliser ps.TEXPRINTER comme valeur de TEXDEVICE ce qui indique à dvips d'utiliser les réglages pour TEXPRINTER dans la traduction de DVI vers PostScript. Il est enfin possible d'assigner une liste de formats de sortie à TEXDEVICE.

    Brouillons et traitements multiples

    Certains formats — dont LaTeX — et certaines macros exigent de votre manuscrit qu'il soit traité plusieurs fois par TeX ou LaTeX avant que vous n'obteniez la version finale. Le module latex.tex.mk impose un traitement à multiples passes de votre manuscrit, car LaTeX s'appuie sur ce mécanisme pour produire les références croisées associées aux commandes label ou ref de votre manuscrit. Le module doc.tex.mk ne procède pas à un traitement multiple.

    Dans les premiers jets d'un document, les modifications sont probablement fréquentes ; il est donc souhaitable d'éviter de longs traitements multiples. bsdowl a un mode brouillon, activé en assignant la valeur yes à la variable DRAFT de make. Ceci peut être fait en ajoutant la commande suivante dans le Makefile:

    DRAFT?= yes
    DOC = script.tex
    .include "latex.doc.mk"

    La commande DRAFT?= est une forme faible de l'assignement qui permet d'invoquer make DRAFT=no pour rétablir le traitement à plusieurs passes pour une unique invocation de make, sans modifier le Makefile.

    Lorsque les derniers ajustements ont été faits au manuscrit, vous pouvez supprimer la commande manipulant DRAFT et votre texte est prêt pour une dernière exécution de make produisant la version finale de votre document. Si vous en êtes satisfait, vous pouvez l'installer.

    Pendant la mise au point d'un document, il est utile de garder des copies des documents produits à certaines étapes de votre travail. Imaginez envoyer un exemplaire préliminaire de votre travail à un ami qui le lira attentivement et vous fera part de ses commentaires. Pendant ce temps, vous continuez de travailler sur votre texte, si bien que lorsque vous recevrez ses commentaires, votre document aura évolué. Pour pouvoir comparer les commentaires de votre ami à la version de votre document que vous lui avez envoyé, la meilleure manière de résoudre ce problème est probablement d'utiliser un outil de gestion des versions — un logiciel gardant note des différentes révisions d'un fichier. Si vous n'utilisez pas un tel système et désirez en essayer un, vous pourriez être intéressé par GIT, tout particulièrement si vous utilisez les courriels pour organiser votre collaboration.

    Lorsque la variable DRAFT est positionnée à yes et la variable TEXDRAFTSTAMP n'est pas initialisée, elle reçoit la valeur -${TEXDRAFTTIMESTAMP} où le texte de remplacement de TEXDRAFTTIMESTAMP est la date à laquelle la commande make est appelée. Lorsque la variable TEXDRAFTSTAMP est initialisée et n'est pas vide, son texte de remplacement est ajouté à la fin de tous les documents installés par latex.doc.mk ou tex.doc.mk. Si vous ne souhaitez pas que le nom soit modifié, tout en utilisant le mode brouillon, il suffit d'affecter un texte vide à TEXDRAFTSTAMP.

    Un document dans plusieurs fichiers

    Si vous travaillez sur un document complexe, vous aurez certainement découpé votre manuscrit en plusieurs fichiers ; typiquement, un fichier par chapitre ou par section plus un fichier principal contenant le préambule et de multiples commandes input demandant à LaTeX de lire tous les fichiers représentant le véritable contenu du document.

    Supposons donc que votre document est découpé entre un fichier principal galley.tex et deux fichiers part1.tex et part2.tex. Votre galley.tex ressemble probablement à ceci :

    \documentclass{article}
    \begin{document}
    \input{part1}
    \input{part2}
    \end{document}

    Le Makefile correspondant est alors :

    DOC = galley.tex
    SRCS = part1.tex
    SRCS+= part2.tex
    .include "latex.doc.mk"

    Fonctions avancées

    Figures avec METAPOST

    Les modules latex.doc.mk et tex.doc.mk prennent en charge
    METAPOST agréablement. C'est un point particulièrement important à relever, car METAPOST est souvent l'outil le mieux adapté pour tracer des figures destinées à l'inclusion dans un document TeX. Cependant, il n'est que rarement pris en charge de façon adéquate par les interfaces graphiques LaTeX.

    Ces modules font l'hypothèse que votre code METAPOST contient les lignes :

    prologues := 3;
    outputtemplate := "%j-%c.mps";
    

    La première déclaration paramètre l'inclusion des fontes dans le fichier résultat tandis que la seconde change le format des noms utilisés par les produits.

    Supposons donc que vous ayez préparé les illustrations pour votre article avec METAPOST et réparti ces illustrations dans deux fichiers illustr1.mp et illustr2,mp. Pour indiquer à latex.doc.mk qu'il doit les utiliser pour produire leurs figures, définissez la variable FIGS dans votre Makefile:

    DOC = galley.tex
    SRCS = part1.tex
    SRCS+= part2.tex
    FIGS = illustr1.mp
    FIGS+= illustr2.mp
    .include "latex.doc.mk"

    Saisissez donc make à l'invite de commande. Le module latex.doc.mk analysera vos fichiers pour savoir quelles illustrations sont définies dans vos fichiers et produira les fichiers nécessaires à votre TEXDEVICE. Par exemple, si votre TEXDEVICE est dvi et que illustr1.mp contient la description de deux figures définies par beginfig(1) et beginfig(2), alors vous obtiendrez quatre fichiers :

    % ls *.mps
    illustr1-1.mps
    illustr1-2.mps
    illustr1-1.eps
    illustr1-2.eps

    Les deux premiers fichiers sont la sortie de METAPOST, des données intermédiaires dans un format PostScript spécifique. Les deux derniers sont en Encapsulated PostScript et adaptés à l'inclusion dans votre document.

    En utilisant le paquet graphicx, l'inclusion d'image est aussi simple que possible :

    \includegraphics{illustr1-1}%

    Découvrez METAPOST. Il semblerait que de nombreuses personnes ne connaissent pas METAPOST. Si c'est votre cas mais que vous êtes intéressé par la découverte de cet outil merveilleux, la première bonne nouvelle est qu'il fait partie de la plupart — sinon de toutes — les installations de TeX, il est donc probablement déjà installé sur votre système.

    La seconde bonne nouvelle est que de nombreuses informations peuvent être trouvées à son sujet sur le Web. Par exemple le TeX users group a une page dédiée à cet outil. La liste qui s'y trouve est particulièrement longue, j'ajouterai donc que j'ai lu et apprécié l'introduction de André Heck, elle est peut-être un bon point de départ pour vous !

    Enfin n'oubliez pas d'essayer mon projet Metapost blueprint pour produire de splendides graphiques pour accompagner vos projets.

    Bibliographie

    bsdowl peut vous aider à préparer des bibliographies avec BibTeX. Tout d'abord vous devez vous assurer que TeX trouvera les base de données bibliographiques que vous avez énumérées dans vos commandes bibliography. Il est habituel de regrouper ses bases de données bibliographiques dans un dossier, par exemple ${HOME}/share/bib. Pour permettre à bibtex de trouver ses fichiers, il suffit d'ajouter le chemin ${HOME}/share/bib au contenu de la variable BIBINPUTS. Si votre base de données bibliographiques est dispersée dans plusieurs dossiers, vous n'avez qu'à mentionner chacun d'eux dans BIBINPUTS :

    DOC = galley.tex
    SRCS = part1.tex
    SRCS+= part2.tex
    BIBINPUTS = ${HOME}/share/bib
    BIBINPUTS+= ../morebib
    .include "latex.doc.mk"

    Notez que le mantra make clean laissera intacts les fichiers BBL produits par bibtex. Les éditeurs demandent parfois de leur envoyer ces fichiers, ainsi, la commande make clean ou make distclean placera votre dossier de travail dans un état où vous pourrez facilement le redistribuer. Pour vous débarrasser des fichiers BBL, vous devez vous en remettre au puissant mantra make realclean.

    Plusieurs documents dans le même dossier

    Bien qu'il soit souvent une bonne idée de réserver un dossier à chaque document, vous pouvez avoir des raisons de vouloir travailler avec plusieurs documents dans le même dossier. Vous avez vos raisons et elles sont probablement excellentes, et bsdowl fera donc de son mieux pour vous aider.

    Supposons que vous ayez deux documents dont les sources se trouvent dans le même dossier, disons un article et une version abrégée de cet article. Ces deux documents ont en commun un fichier macro.tex, mais sont à part cela relativement indépendants du point de vue de LaTeX. Le texte de l'article est divisé dans deux fichiers section1.tex et section2.tex. Le résumé a un seul fichier summary.tex. Le Makefile correspondant ressemble à ceci :

    DOC = article.tex
    DOC+= summary.tex
    
    SRCS = macros.tex
    
    SRCS.article.tex = section1.tex
    SRCS.article.tex+= section2.tex
    
    .include "latex.doc.mk"

    Génération automatique d'une portion de document

    Supposons que vous travailliez sur un document contenant une table dont le contenu changera vraisemblablement plusieurs fois et devra donc être mis à jour. Une telle table pourrait être un budget : lorsque notre situation évolue, ainsi en va-t-il de notre budget. Il peut être assez délicat de saisir une table en LaTeX, la mettre à jour est encore plus vachard. Dans cette situation, on peut écrire et utiliser à profit un petit programme lisant les données brutes de notre budget et écrivant pour nous le code LaTeX de la table correspondante, contenant cette information brute et les données que nous pouvons en dériver. Écrire un tel programme est très facile, car on a seulement besoin de savoir travailler avec des fichiers texte.

    Ainsi, vous avez rassemblé vos données brutes pour votre table dans le fichier table.raw et écrit un petit programme gentable qui écrit pour vous la table LaTeX sur sa sortie standard. Dans votre manuscrit, vous utilisez le nom table pour inclure le contenu de la table. Voici votre Makefile:

    DOC = galley.tex
    
    table.tex: gentable table.raw
        ./gentable < table.raw > table.tex
    
    REALCLEANFILES+= table.tex
    
    .include "latex.doc.mk"

    Cet exemple suppose que le programme gentable est un filtre, de sorte que l'entrée et la sortie sont effectuées par des redirections. D'autres programmes peuvent utiliser une convention différente pour définir la sortie et l'entrée.

    Si vous envoyez vos fichiers à quelqu'un, cette personne ne voudra probablement pas exécuter votre programme gentable . Il semble donc préférable d'ajouter le nom du produit table.tex à REALCLEANFILES plutôt qu'à CLEANFILES : vous pouvez ainsi nettoyer votre dossier de travail avec make clean et faire une archive du contenu que vous enverrez à un tiers, sans avoir besoin de traiter le fichier table.tex avec une attention particulière.

    Bien sûr, vous pouvez générer un code source pour METAPOST, typographier un fragment de code ou bien encore autre chose, au lieu de générer une table !

    Code source réparti dans plusieurs répertoires

    Certaines méthodes de travail requièrent que vos fichiers source ne soient pas situés dans un répertoire unique mais disséminés dans le système de fichiers.

    Une raison pour travailler ainsi pourrait être que votre organisation utilise pour son courrier une classe de document personnalisée incluant quelques images. Vous ne souhaitez pas copier ces images dans chacun des dossiers utilisant cette classe de document, ni créer des liens symboliques vers ces images : vous souhaitez tout bonnement pouvoir ignorer leur existence ! Une solution à ce problème passe par la variable TEXINPUTS dont le contenu est une liste de dossiers que TeX doit examiner lorsqu'il recherche un fichier.

    Une autre raison motivant la dissémination de fichiers sources dans plusieurs dossiers est la préparation d'un grand document, comme un livre. Si les fichiers de chaque chapitre sont contenus dans un dossier dédié, il est facile de traiter un chapitre isolé avec LaTeX pendant la phase de mise au point du manuscrit. TeX doit donc trouver tous les fichiers nécessaires lorsqu'il traite le fichier principal produisant le livre, ce qui est accompli en positionnant TEXINPUTS à la valeur adéquate, comme expliqué ci-dessous.

    Vous pouvez définir la variable TEXINPUTS dans votre environnement, dans votre Makefile ou bien même écrire une version personalisée de latex.doc.mk définissant cette variable.

    Supposons que l'image représentant visuellement votre organisation soit dans ${HOME}/share/texmf/tex/organisation/visual.eps, afin que TeX examine le dossier contenant cette image, vous écrivez une affectation à TEXINPUTS dans votre Makefile, comme ceci :

    DOC = galley.tex
    TEXINPUTS = ${HOME}/share/texmf/organisation
    .include "latex.doc.mk"

    Exécuter make dans le dossier contenant le Makefile fera apparaître ceci dans votre terminal :

    % make
    make build
    ===> Multipass job for galley.dvi (aux)
    env TEXINPUTS=".:${HOME}/share/texmf/organization:" latex galley.tex
    This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
    ...

    Examinons la liaison associée à TEXINPUTS par la commande env. Elle se distingue notamment de la spécification du Makefile par la présence d'un élément . au début et d'un élément vide à la fin. Ceux-ci indiquent à TeX de rechercher aussi les fichiers dans le dossier courant et dans les dossiers de l'installation TeX.

    Si dans un cas particulier vous souhaitez avoir un contrôle total sur TEXINPUTS, il vous suffit de positionner USE_STRICT_TEXINPUTS à yes dans votre Makefile. S'il trouve ce positionnement, bsdowl n'ajoutera pas le point et l'élément vide à TEXINPUTS.

    La prise en charge de METAPOST tient compte des valeurs de TEXINPUTS ET USE_STRICT_TEXINPUTS. Une variable analogue nommée MPINPUTS et sa compagne USE_STRICT_MPINPUTS permettent de configurer le chemin de recherche des fichiers par METAPOST.

    Travailler avec des collections contenant un grand nombre de documents

    Nous montrons comment utiliser le module bps.subdir.mk pour organiser une collection de documents. Pour les besoins de cet exemple, nous supposerons que vous préparez un journal électronique et souhaitez distribuer chaque article du journal comme un document individuel. Vous utilisez l'organisation suivante :

    1. Vous avez préparé un répertoire contenant chaque numéro du journal, disons ${HOME}/journal.
    2. Chaque numéro du journal est matérialisé par un sous-répertoire du dossier précédent.
    3. Chaque article du journal est représenté par un sous-répertoire du dossier correspondant au numéro auquel il appartient.

    Supposons que vous avez déjà préparé plusieurs articles, comme le suggère la commande suivante :

    % find ./journal -type f
    ./journal/issue-2013-1/01-galdal/Makefile
    ./journal/issue-2013-1/01-galdal/article.tex
    ./journal/issue-2013-1/02-arathlor/Makefile
    ./journal/issue-2013-1/02-arathlor/article.tex
    ./journal/issue-2013-2/01-mirmilothor/Makefile
    ./journal/issue-2013-2/01-mirmilothor/article.tex
    ./journal/issue-2013-2/02-eoron/Makefile
    ./journal/issue-2013-2/02-eoron/article.tex
    ./journal/issue-2013-2/03-echalad/Makefile
    ./journal/issue-2013-2/03-echalad/article.tex

    Les noms comme galdal, arathlor, etc. sont les noms des auteurs fictifs des articles non moins fictifs de votre journal. Chaque contribution est associée à un répertoire contenant le texte de l'article proprement dit article.tex et un Makefile semblable à ceux décrits plus haut dans cette dépêche et qui est utilisé pour préparer l'article correspondant.

    Chacun de ces Makefile peut être aussi simple que:

    DOC=    article.tex
    .include "latex.doc.mk"

    Pour coordonner la préparation de tous nos articles, il nous suffit d'écrire quelques Makefile supplémentaires :

    ./journal/Makefile
    ./journal/issue-2013-1/Makefile
    ./journal/issue-2013-2/Makefile
    ./journal/issue-2013-3/Makefile
    

    Chaque Makefile contient essentiellement la liste des sous-répertoires que make doit explorer pour atteindre les cibles build, install ou clean. Ainsi le fichier ./journal/Makefile doit contenir :

    SUBDIR=     issue-2013-1
    SUBDIR+=    issue-2013-2
    SUBDIR+=    issue-2013-3
    .include "bps.subdir.mk"

    Quant à lui, ./journal/issue-2013-1/Makefile doit contenir :

    SUBDIR=     01-galdal
    SUBDIR+=    02-arathlor
    .include "bps.subdir.mk"

    Les fichiers restants ./journal/issue-2013-2/Makefile et ./journal/issue-2013-3/Makefile doivent être préparés de façon similaire. Avec ces ajustements, les cibles all, build, clean, distclean, realclean et install sont déléguées aux Makefile trouvés dans les dossiers énumérés par SUBDIR.

    La variable _SUBDIR_PREFIX peut être utilisée pour personnaliser le dossier d'installation pour chaque article. Changeons le Makefile associé à chaque article en :

    DOC=    article.tex
    DOCDIR= ${HOME}/publish/journal${_SUBDIR_PREFIX}
    .include "latex.doc.mk"

    Avec ce réglage, le document ./journal/issue-2013-1/01-galdal/article.dvi sera installé dans ${HOME}/publish/journal/issue-2013-1/01-galdal/article.dvi et ainsi de suite. Il est possible d'ajuster ceci pour utiliser un police de nommage complètement arbitraire pour l'installation des produits.

    Contribuer

    Le but de bsdowl est de fournir un système de déploiement de logiciel portable pour les systèmes UNIX modernes. Il se distingue d'autres approches par l'utilisation de simples fichiers Makefile et d'un programme standard : BSD Make. L'utilisateur de bsdowl écrit donc des fichiers Makefile, il n'est pas utile d'apprendre un énième langage de script pour écrire une spécification de compilation.

    Pour la version 3.0 en préparation, je projette de réorganiser grandement le logiciel. Les projets sont :

    • Mise en avant des notions de module et de produit, pour se rapprocher du schéma d'organisation des projets dans les grands IDE classiques.
    • Concilier le point précédent avec une approche non bureaucratique pour les petits projets.
    • Utiliser de façon systématique un mode de développement axé sur les tests.

    Si vous êtes intéressé(e) par bsdowl vous pouvez :

    • témoigner de votre intérêt en lui ajoutant une petite étoile dans GitHub ;
    • rapporter vos succès et vos infortunes, je suis notamment très intéressé par la préparation d'une liste de compatibilité.
    • contribuer des programmes de type hello-world ou de plus complexes pour m'aider à écrire des tests pour les langages que vous aimeriez voir pris en charge.

    Lire les commentaires

  • test (Journaux LinuxFR)
  • Adblock vous épargne désormais les alertes aux cookies ! (Journaux LinuxFR)

    C'est un journal bookmark de toute évidence. Je suis tombé sur cet article qui décrit la souffrance du monde entier sur les sites hébergés en Europe.

    Adblock propose ssur cette page des listes additionnelles que vous pouvez suivre. Parmi elles, tout en bas, figure celle qui vous évitera les messages type "En surfant ici vous acceptez les cookies".

    Ces messages sont particulièrement agaçants, bien que dans une démarche de transparence, car tous les sites non visités vous avertissent d'une généralité du Web. Le problème, c'est que ces messages se basent sur l'usage… de cookies pour être cachés ! Une aberration qui conduit les utilisateurs de Firefox, ayant paramétré un reset complet des cookies à la fermeture du logiciel, à subir encore et encore ces messages indéfiniment.

    Résultat, Linkedin semble ne pas trop apprécier, pour le reste du Web c'est juste incroyable d'arriver sur un site sans se faire agresser !

    Je me rends soudain compte qu'Adblock n'est pas réductible à un simple bloqueur de pubs, et ce depuis ses débuts puisqu'il l'a toujours permis. D'autres filtres permettent de ne plus afficher les faux scans antivirus (bien utile pour vos proches débutants) ou encore les messages de rébellions contre Adblock lui-même.

    Je suis toujours épaté du service que me rend ce script. Je ne sais pas pourquoi mais je sens que j'aurais dû attendre une demi heure avant de poster.

    Lire les commentaires

  • Mozilla location services: quand il faut choisir entre liberté et vie privée (Journaux LinuxFR)

    Récemment, Mozilla travaille sur les location services, un service geolocalisation à partir du wifi ou du réseau cellulaire, qui a vocation a être intégré dans Firefox/Firefox OS. C’est un service très utile, à un détail près: il est propriétaire.

    Les principaux écosystèmes mobiles ont un service de geolocalisation à partir du wifi: c’est très rapide, et pratique quand on a pas de GPS sur sa tablette. C’est aujourd’hui une fonctionnalité incontournable pour un smartphone. Le principe est simple: on envoie la liste des points d’accès wifi qu’on voit et leur puissance à un serveur, qui va ensuite nous renvoyer notre position. Les mobiles qui demandent ces données participent aussi à les remonter une fois le GPS verrouillé: c’est du donnant-donnant.

    Mais il peut y avoir des dérives; on se souviendra d’Apple qui stocke l’historique des positions sur les iPhones, des inquiétudes autour de la collecte de Microsoft, ou de celle des Google cars qui enregistraient tout ce qui passait en wifi; ou encore des pratiques anti-concurentielles de Google visant à empécher que Motorola et Samsung utilisent un service de geolocalisation concurrent.

    Mozilla a récemment sortie en version 1.0 Mozilla Stumbler, une appli Android qui permet à l’organisation de bâtir son propre service de geolocalisation: les participants volontaires installant l’application uploadent régulièrement les données des points d’accès wifi alentours associés à leur position GPS. Un système de classement ajoute un aspect gamification et compétition entre les plus gros contributeurs.

    L’application est libre et même dispo sur f-droid pour les plus puristes d’entres nous. Seulement la base de données n’est pas libre.

    On peut accéder aux données de localisation via l’API en demandant des clefs au responsable. On peut même télécharger la base de données des stations cellulaires. Mais impossible de récupérer la base contribuée volontairement pour monter son propre service concurrent.

    Et ce n’est pas sans raison. En effet, les implications au niveau de la vie privée sont assez larges, et les plus exposés sont justement les contributeurs dont on peut déduire leur habitation, l’adresse mac du téléphone-qui-partage-sa-connexion, qui permettront ensuite de les tracker en recroisant des informations.

    Ce dilemme n’est pas sans laisser un goût amer; alors qu’on aurait pu espérer un service analogue à OSM, on a clone de Google Maps pour la localisation. Le service est fourni par une organisation plus amicale, mais peut s’arrêter du jour au lendemain, et toutes ses données s’évaporeront laissant la communauté reconstruire la base de zéro. Mais ouvrir la base, c’est exposer la vie privée de tout le monde (utilisateur ou pas) à une exploitation non contrôlée.

    Pensez-vous que Mozilla fait le bon choix ?

    Lire les commentaires

  • mes-aides.gouv.fr, simulez vos aides en ligne ! (Journaux LinuxFR)

    Pour mon premier journal, je fais un journal bookmark !

    mes-aides.gouv.fr est un site web permettant de découvrir les aides du gouvernements français dont vous pouvez bénéficier. Pour l'instant en bêta, il permet déjà de tester si on peut avoir le droit à certaines aides. L'interface est claire et simple ce qui est rare sur ce genre de site.

    Encore plus rare, il repose sur des outils libre dont Bootstrap, node.js et angular.

    Et encore plus rare, une partie du site est sous licence libre (MIT) avec un github ouvert à tous !

    Le site : http://mes-aides.gouv.fr/
    Les deux dépôts :
    Pour l'API sous licence MIT : https://github.com/sgmap/mes-aides-api
    Pour l'UI sous licence inconnu : https://github.com/sgmap/mes-aides-ui
    La discussion sur reddit, où les développeurs participent : http://www.reddit.com/r/france/comments/2krv9a/mesaidesgouvfr_un_site_exp%C3%A9rimental_de_letat/

    Lire les commentaires

  • L’Académie des sciences française prétend vouloir l’ouverture des publications scientifiques (Dépêches LinuxFR)

    En France, l’Académie des sciences a, parmi ses missions, de conseiller les autorités gouvernementales dans le domaine des sciences. Dans le cadre de cette activité, un rapport a été publié le 24 octobre 2014 pour proposer d’améliorer le fonctionnement de l’édition scientifique.

    Malgré cette volonté affichée d’ouverture, on peut se poser des questions sur ces améliorations. Découvrez la teneur du rapport en seconde partie.

    Après avoir précisé que seule l’évaluation par les pairs permettait d’assurer la qualité d’une publication scientifique, le rapport présente les deux modèles économiques qui existent dans le monde de l’édition scientifique :

    • le lecteur payeur : ce modèle, le plus reconnu actuellement, permet aux chercheurs de publier gratuitement leurs articles mais oblige tous les organismes de recherche souhaitant accéder aux résultats des recherches à s’abonner, à des prix très élevés, à de nombreuses revues scientifiques (en France, cela coûte 75 millions d’euros par an aux universités et 30 millions d’euros aux organismes publics de recherche) ;
    • l’auteur payeur : ce modèle, en pleine croissance, oblige les chercheurs à payer pour publier mais permet que leurs publications soient ouvertes à tous, directement disponibles sur le Web.

    L’académie souhaiterait que le modèle évolue afin d’offrir :

    • des archives ouvertes : toutes les publications scientifiques doivent être à terme (après un délai pouvant être de plus d’un an) mises à disposition de tous afin d’assurer la pérennité de la connaissance scientifique (l’histoire des sciences regorge d’exemples de recherches perdues ou retardées faute d’une diffusion suffisante, par exemple la [[découverte de l’Amérique]], la découverte de Neptune ou la découverte de la pénicilline) ;
    • un accès libre institutionnel : reprenant le principe de l’auteur payeur, l’académie souhaiterait faire évoluer le modèle des publications traditionnelles en proposant de faire payer aux chercheurs français leurs publications en échange d’un « accès libre » par les autres chercheurs français.

    L’idée de l’académie serait que le consortium Couperin, qui négocie les 105 millions d’euros annuels d’achats de publications scientifiques pour la recherche publique française, se charge de proposer la transition aux éditeurs, à coûts constants (les 105 millions d’euros seraient à terme utilisés pour payer la publication), et que le système soit étendu au niveau européen et mondial. Le rapport reconnaît que cela pourrait tuer le vrai open access qui permet la mise à disposition à tous sans attendre les délais d’archivage, mais ne considère pas que ce soit un mal. Par ailleurs, la question des licences des contenus ainsi publiés n’est même pas abordée par le rapport.

    Malgré les constats justes faits par l’Académie des sciences (il faut favoriser la libre diffusion de la connaissance), nous n’avons au final qu’une proposition changeant peu le modèle actuel (la connaissance scientifique fraîche resterait réservée aux riches) et renforçant même les éditeurs responsables des problèmes reconnus par l’académie, mais en y ajoutant partout les termes open et ouvert. On peut trouver ça plus vendeur…

    Lire les commentaires

  • Présentation de Cozy Light une micro PaaS pour s'initier à l'auto-hébergement (Journaux LinuxFR)

    Bonjour tout le monde,

    Aujourd'hui je viens vers vous avec un nouveau projet qui répond au doux nom de Cozy Light. L'idée est venu de le créer en constatant trois choses. Premièrement, les diverses solutions d'auto-hébergement sont souvent un peu trop lourdes pour les petits hardwares tels que le Raspberry Pi (et pourtant 4 millions d'entre eux se baladent dans la nature et ne demandent qu'à se rendre utile !). Deuxièmement leur installation est souvent trop complexe (il faut souvent se rabattre sur une "image"). Et enfin la manière de contribuer au code n'est pas toujours évidente.
    En bref, quand on veut s'auto-héberger, même une simple configuration de Nginx peut s'avérer rebutante surtout quand une fois arrivé au but on se rend compte que ça mouline sévère sur notre Pi.

    Et c'est là qu'arrive Cozy Light qui permet de gérer son infrastructure comme un assemblage de lego. On part d'une plateforme minimaliste (800 lignes de codes en JS) qui s'installe en deux lignes de commandes. Ensuite on ajoute les plugins dont on a besoin pour réaliser les actions souhaitées comme déployer un blog ou associer un nom de domaine à une app. De cette manière on peut donner différents visages à sa machine et en faire un cloud personnel, une console de jeu vidéo HTML5 ou même un serveur pour son site web et son blog. Cozy Light supporte par défaut des applications Node.js avec des bases de données embarqués. Pour les applications plus évoluées il faudra passer par Docker.

    Voici un exemple pour le déploiement d'un site statique et d'un moteur de blog :

        # Installation (pour Ubuntu 14.04)
        sudo apt-get install git npm nodejs-legacy
        sudo npm install cozy-light -g
        # Configuration des plugins 
        cozy-light add-plugin cozy-labs/cozy-light-html5-apps # pour déployer le site web statique
        cozy-light add-plugin cozy-labs/cozy-light-docker # pour déployer le blog
        cozy-light add-plugin cozy-labs/cozy-light-domains
        # Installation du site web statique
        cozy-light install monutilisateurgithub/monsite
        # Installation du moteur de blog Ghost
        cozy-light install-docker frankrousseau/ghost # Un manifeste spécifique est requis pour les apps Cozy Light.
        # Configuration des domaines et du githook
        cozy-light link-domain monsiteweb.fr monutilisateurgithub/monsite
        cozy-light link-domain www.monsiteweb.fr monutilisateurgithub/monsite
        cozy-light link-domain blog.monsiteweb.fr frankrousseau/ghost
        # Démarrage de la plateforme sur le port 80 (attention aux droits)
        cozy-light start --port 80

    Et voilà si vous avez fait les redirections qui vont bien, le blog Ghost est accessible sur blog.monsiteweb.fr et votre site sur www.monsiteweb.fr ! Attention Docker n'est pas disponible sur Raspberry Pi mais vous pouvez tout de même deployer votre site web statique et si vous être patient porter Ghost en application standard pour Cozy Light (étant donné que c'est du node.js).

    Deuxième exemple : le cloud personnel

        # Configuration des plugins 
        cozy-light add-plugin cozy-labs/cozy-light-auth
        # Installation des applications
        cozy-light install cozy-labs/calendar
        cozy-light install cozy-labs/files
        cozy-light install cozy-labs/contacts
        # Mise en place de l'authentification
        cozy-light add-plugin cozy-labs/cozy-light-basic-auth
        cozy-light set-password # affiche un prompt masqué pour récupérer le password
        # Configuration des domaines
        cozy-light link-domain calendrier.monsiteweb.fr cozy-labs/calendar
        cozy-light link-domain fichiers.monsiteweb.fr cozy-labs/files
        cozy-light link-domain contacts.monsiteweb.fr cozy-labs/contacts
        # Démarrage de la plateforme sur le port 80 (attention aux droits)
        cozy-light start --port 80

    Et voilà on a nos trois apps accessibles via un joli nom de domaine !

    Pour finir, comme je le mentionnais au début, il est facile de contribuer en code à la plateforme grâce à l'architecture en greffons. Certains font à peine trente lignes de codes et apporte des fonctionnalités intéressantes. J'ai même pu en faire un en moins d'une heure !

    Si vous aimez le projet n'hésitez pas à mettre une étoile sur le dépôt ou à en parler autour de vous. Si vous vous sentez à l'étroit avec Cozy Light et que voulez des solutions plus évoluées jetez une oeil à Yunohost, Arkos, Owncloud et bien sûr Cozy en version complète !

    Et pour finir voici deux liens et un nuage content :

    Titre de l'image

    Lire les commentaires

  • Tamashare : salle virtuelle interactive pour vos activités collaboratives (Dépêches LinuxFR)

    Tamashare est une application vous permettant de travailler à distance comme si vous étiez dans la même pièce (NdM : disponible sous GNU/Linux, au moins Debian amd64, mais propriétaire) .

    Pour immerger les utilisateurs dans une ambiance « salle de réunion » nous ajoutons à la voix et la vidéo, les mains et la table de travail.

    L’expérience de travail est « hyper interactive » et ludique. Extrêmement simple d’utilisation, Tamashare s’adresse à tout public.

    Tamashare propose la location de salle virtuelle interactive balayant ainsi les problèmes de coûts et de disponibilité d’une vraie salle de réunion tout en gardant ses avantages.

    Pour finir, Tamashare respecte la confidentialité et la sécurité car les données ne sont pas stockées sur le cloud.

    NdM : en ces temps de campagne Dégooglisons Internet, citons quelques solutions libres pour les activités collaboratives à distance comme BigBlueButton ou Jitsi (et d'autres solutions comme Ekiga, Pidgin, le code libre derrière Talky.io, Firefox Hello, etc. si on retire le besoin de bureau partagé ou de tableau partagé).

    Lire les commentaires

  • Appel à participations pour OSDC.fr 2014 (Dépêches LinuxFR)

    Le 22 novembre 2014, les associations les Mongueurs de Perl, l'AFPy (Association Francophone Python), Ruby France, l'European Smalltalk User Group et l'Association Française des Utilisateurs de PHP organisent la 6e Open Source Developers Conference France à la Cité des Sciences et de l'Industrie de Paris.

    OSDC.fr est une conférence qui vise à rassembler les développeurs francophones autour de technologies innovantes ou plus anciennes, notamment autour des langages de programmation libres et open source : Perl, Python, Ruby, PHP, Smalltalk, Javascript, Ceylon, etc., et leurs déclinaisons.

    Cette année, OSDC.fr se tient sur une seule journée, et opère un retour aux sources à La Cité des Sciences, lieu des premières réunions.

    OSDC.fr vous invite à proposer des conférences ou à nous rejoindre le 22 novembre 2014 à la CdSI. Les présentations peuvent durer 25 ou 45 minutes. Il y aura aussi une session de présentations éclair dont la durée est limitée à cinq minutes par présentation. L'entrée est libre et gratuite.

    Dates importantes :

    • date limite pour proposer une présentation : 17 novembre 2014 ;
    • programme final : 19 novembre 2014 ;
    • conférence OSDC.fr : 22 novembre 2014.

    Lire les commentaires

  • Le Libre cheZot à Saint-Joseph de la Réunion le 1er novembre 2014 (Dépêches LinuxFR)

    Le GUL Libre974 vous invite à une journée de promotion des logiciels libres et de la culture libre à Saint-Joseph de la Réunion le samedi 1er novembre 2014 de 10h à 18h au café culturel "CheZot", ouverte à tout public.

    Des ateliers de démonstration seront proposés tout au long de la journée aux visiteurs de tous niveaux allant du simple curieux au technophile averti.

    Divers espaces seront proposés avec entre autres :

    • un atelier dédié à la publication assistée par ordinateur sous Scribus ;
    • un atelier sur la découverte des mini-ordinateurs Raspberry Pi et leurs applications ;
    • un espace démonstration de la distribution GNU/Linux choisie pour l'occasion : Ubuntu 14.04 ;
    • un espace Install Party sera également proposé, alors n'hésitez pas à venir avec votre ordinateur pour vous faire accompagner dans l'installation d'une distribution Linux ;
    • un espace détente avec de la musique libre en fond sonore provenant du site Jamendo.

    Le libre CheZot Deuxième édition

    L'entrée est libre et gratuite, alors venez nombreux !

    Lire les commentaires

  • Lollypop: un autre lecteur audio pour GNOME (Journaux LinuxFR)

    Bonjour,

    il y'a quelques mois, j'ai commencé à me lasser de certains bugs présents dans KDE, en particulier dans KDEPIM.

    J'ai donc du coup migré pour test sous Elementary OS mais la version stable n'offre pas d'outils de PIM satisfaisants…

    Puis je me suis dit que gnome shell + plank (le dock d'EOS) ce serait peut être pas mal… Puis je me suis habitué au workflow de gnome-shell et maintenant je l'utilise sans dock ni extensions. Comme quoi, c'est vrai que on finit par prendre ses repères… Le seul truc que je trouve relou, c'est qu'il est vraiment plus lent que Kwin, y'a pas photo!

    Bref, ça c'est pour ceux qui auraient suivi mes quelques contributions sur le projet KDE, rien de neuf pour moi, j'ai suivant les années utilisé l'un puis l'autre environnement.

    Par contre pour lire de la musique, j'avais un problème:

    • gnome-music rame complètement pour utiliser ma bibliothèque, genre avec le 3.14, il faut juste 10 minutes pour que je puisse accéder à quoi que ce soit… Je suis pas sur que de bombarder tracker de requêtes soit très efficace, en regardant le code source, je n'ai vu que ce goulot d'étranglement.
    • rhythmbox rame lui aussi, pas étonnant vu que le bibliothèque est stockée dans un fichier xml, j'ai envie de dire: WTF?
    • Le player de Elementary OS rame moins mais je n'aime pas l'IHM et Budgie, lui, ne termine jamais le scan de ma bibliothèque

    J'ai donc utilisé clementine un petit moment puis en voyant les nouveaux concepts présents (lié à la nouvelle headerbar) dans les applications GNOME, il y'a un mois, je me décide à coder mon propre lecteur basé sur python, SQLite et gstreamer: Lollypop
    https://github.com/gnumdk/lollypop

    Screenshot

    C'est un mélange entre certains concepts d'Amarok et d'autres de GNOME music, c'est sûrement encore bourré de bugs mais chez moi ça marche et hier il a gobé la collection de mon colloc macosxiste sans broncher, je pense donc qu'il est temps de faire un peu de pub ;)

    Au menu:

    • Navigation par style/artist/album ou artist/album
    • Téléchargement des pochettes d'albums via un simple click
    • Vue contextuelle de l'artiste en cours de lecture
    • Mode soirée configurable en fonction du style
    • Vue des albums populaires
    • Recherche dans la bibliothèque
    • La liste de lecture courante est seulement contextuelle (où j'étais quand j'ai chargé le morceau)
    • Liste d'attente
    • Replay gain/gapless

    Voilà, merci de votre attention et n'hésitez pas à faire des rapports de bug sur github ;)

    Lire les commentaires

  • Actualités des systèmes d’information géographique (Dépêches LinuxFR)

    Quelques nouvelles du monde des systèmes d’information géographique (SIG), qui, d’après le Wikipédia francophone « est un système d’information permettant de créer, d’organiser et de présenter des données alphanumériques spatialement référencées, autrement dit, géoréférencées, ainsi que de produire des plans et des cartes ».

    Retrouvez dans la seconde partie de la dépêche les annonces des nouvelles versions (Geoserver, pycsw, OpenLayers, PostGis, OSGeo, GDAL…), les services (OpenStreeMap), les événements (Foss4g et Be-OpenGIS-fr) .

      Nouvelles versions

      Geoserver 2.6.0 : serveur web pour données géospatiales;

      pycsw 1.10.0 : serveur permettant de référencer et cataloguer ses données géospatiales en respectant le standard Catalog Service for the Web;

      OpenLayers 3.0 : bibliothèque JavaScript pour la réalisation d'applications Web cartographiques;

      PostGis 2.1.4 : extension pour le stockage d’informations géographiques dans une base PostgreSQL;

      OSGeo-Live 8.0 est un DVD amorçable d’Open Source Geospatial Foundation, contenant une cinquantaine d’applications ;

      GDAL 1.11.1 : correction de bugs pour GDAL le couteau suisse du SIG.

      Futures versions

      La version 2.6 de QGIS est en préparation, voici un aperçu des nouveautés annoncées.

      Au foss4g-FR les développeurs de Mapserver nous ont fait saliver sur les nouveautés de la future version 7.

      Services

      OpenStreetMap a fêté ses 10 ans cet été.

      Quelques illustrations des contributions à OpenStreetMap à travers le monde et quelques indicateurs chiffrés.

      Événements

      Le rendez-vous des géomaticiens libristes c'est le Free and Open Source Software for Geospatial (foss4g). Il se décline en une rencontre annuelle et des rencontres locales :

      • foss4g 2014 : Portland, Oregon, USA, qui a eu lieu du 8 au 13 septembre 2014;
      • Be-OpenGIS-fr 2014, Bruxelles, Belgique le 6 novembre 2014;
      • foss4g-asia : Bangkok, Thailande, du 2 au 5 décembre 2014;
      • FOSS4G-Europe 2015 (Como, Italie) du 14 au 17 juillet 2015.

      Et du côté des cartes

      40 cartes qui expliquent Internet

      Lire les commentaires

    • HandyLinux 1.7 est disponible et adopte le navigateur Iceweasel (Dépêches LinuxFR)

      HandyLinux, dérivée officielle de Debian pour les grands débutants en informatique, embarquait depuis sa version 1.0 le navigateur web Chromium, choisi pour ses fonctions d'accessibilité. La grande nouveauté de la version 1.7 publiée le 19 octobre 2014 est le passage à Iceweasel comme navigateur web par défaut. Iceweasel est directement issu des dépôts Mozilla, ce qui permet d'intégrer la version "Iceweasel-release", actuellement iceweasel-33.

      HandyLinux-1.7 arrive aussi avec le HandyMenu-2.3 qui voit disparaître le bouton facebook au profit d'un lien direct vers les services libres Framasoft : HandyLinux s'associe à la campagne Dégooglisons Internet !

      (NdM : la capture ci-dessous, comportant d'autres solutions centralisées, montre qu'il s'agit d'une première étape ou bien d'un choix supplémentaire offert à l'utilisateur)

      HandyLinux-handymenu-internet

      Comme les versions précédentes, HandyLinux-1.7 est distribuée sous deux branches : 486 (pour les anciens ordinateurs) et 686-pae (pour les ordinateurs modernes).

      Changelog HandyLinux-1.6.1 -> 1.7 :

      • passage à Iceweasel-release comme navigateur par défaut ;
      • refonte de la page de démarrage internet Handylinux startpage ;
      • ajout de gpart pour la récupération de données depuis Gparted ;
      • ajout de yelp pour l'aide directe des logiciels Gnome ;
      • nettoyage de la documentation intégrée en fonction de la langue après installation ;
      • mise à jour du handymenu : remplacement du bouton Facebook par Framasoft ;
      • ajout des "lanceurs sociaux" permettant de glisser directement les liens sociaux (G+, FB; Tw…) depuis la liste des applications ;
      • ajout du lanceur Diaspora ;
      • ajout du firmware-ralink ;
      • réduction de la fenêtre d'accueil pour les netbooks ;
      • ajout d'un thème Tron xfwm4 ;
      • mises à jour Debian-7.7.

      Afin de vous faire profiter au mieux de votre nouveau navigateur, une série d'addons a été intégrée.

      Les plugins de base installés et activés par défaut :

      • adblock-edge pour les pubs ;
      • video download helper pour les vidéos youtube ;
      • gnotifier pour les notifications firefox sur le bureau ;
      • google search image dans le menu ;
      • google translator pour firefox ;
      • print pages to pdf pour créer un pdf avec tous les onglets ouverts ;
      • showcase pour une gestion simplifiée et visuelle des onglets ;
      • tab badge pour une alerte sur les onglets ;
      • tabscope pour un aperçu des onglets au survol du pointeur ;
      • turn of the lights pour un visionnage aisé des vidéos ;
      • youtube allhtml5 pour le HTML5 partout sur youtube ;
      • scroll progress pour indiquer le pourcentage de la page.

      Les plugins d'accessibilité installés mais désactivés par défaut :

      • font & size changer pour modifier l'apparence des sites ;
      • image zoom pour un zoom spécifique des images dans le menu contextuel ;
      • tranquility pour faciliter la lecture ;
      • blank your monitor & easy read pour les soucis de vue ;
      • color full tabs pour une visibilité colorée des onglets ;
      • foxvox pour la synthèse vocale ;
      • fxkeyboard pour le clavier virtuel ;
      • new scrollbar pour modifier l'apparence des barres de défilement.

      Passage à Iceweasel…

      Qu'est-ce qu'on y perd  ? La reconnaissance vocale lors de la recherche Internet, mais pas pour longtemps grâce à pocketvox !

      Qu'est-ce-qu'on y gagne ? Même si Chromium est un fork libre de Google Chrome, il utilise les outils Google. Les activités et la politique générale de Google sont de moins en moins compatibles avec l'idée que l'on se fait d'Internet et de ses outils (voir article sur la dégooglisation d'internet). Iceweasel, la version "démarquée" de Firefox pour Debian, est issue de la fondation Mozilla, acteur essentiel du monde du logiciel libre. Pour répondre simplement, on y gagne notre liberté :)

      Lorsque vous aurez installé cette distribution complète pour les tâches ordinaires, vous pourrez passer à Debian en une minute avec Handy2Debian.

      Lire les commentaires

    • Libreoffice 4.3 : Bug 81633 du tri : "It's not a bug, it's a feature !" (Journaux LinuxFR)

      Adihshats monde, bonjour à tous.

      Ceci est un message d'informations qui peut sauver des données, et aussi un coup de gueule.

      Je tiens ma comptabilité personnelle sur une feuille de calcul Opencalc. Et j'utilise le tri, bien entendu. Ce qui a fonctionné correctement, jusqu'à la version 4.3.

      M'apercevant que le tri disfonctionne(*) avec cette version, je cherche un peu, et je trouve le rapport de bug 81633.

      My english is not good, mais, si j'ai bien compris, un nouveau comportement du tri (mise à jour automatique des références relatives) a été implanté.

      Fort bien, mais tous ceux (dont moi) qui utilisent le fait que lors du tri les références relatives ne sont PAS mises à jour voient leurs documents possiblement corrompus.

      Le contournement, retourner à la version 4.1.

      Je doute fortement que ce genre de modifications plaise aux utilisateurs lambda.

      (*) Oui, "disfonctionne" avec un "i", car pour moi un tri qui fonctionne mal ne fonctionne pas du tout !

      Lire les commentaires

    • Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ? (Journaux LinuxFR)

      J’écris cet article pour vous raconter ma mésaventure et vous avertir des problèmes au devant desquels vous allez si vous décidez de packager pour Debian un logiciel que vous avez vous-même créé. C’est en quelque sorte une réponse à https://wiki.debian.org/AdvantagesForUpstream.

      Je suis le créateur du jeu MiceAmaze, un petit jeu avec des souris et des serpents que j’ai écrit en C++ et qui utilise OpenGL pour le rendu. Le jeu est conçu dès l’origine pour marcher à la fois sous Windows et Linux.

      Dès le début, j’étais conscient que pour que le package soit inclus dans Debian, il fallait respecter certaines conventions comme placer aux bons endroits les fichiers (dans /usr/share les data, dans /usr/bin les binaires, etc.) et qu’il fallait fournir une page de man, un Makefile compatible avec le système de compilation de Debian, etc. Mais le problème n’est pas là.

      Le problème c’est que si vous êtes le créateur du logiciel que vous essayez d’inclure à l’archive Debian, il ne faudra pas simplement que le packaging soit fait correctement, mais que le design de votre logiciel convienne aux responsables de chez Debian.

      Tout d’abord on m’a demandé de changer la manière dont le texte est affiché à l’écran. Je commence par ça car c’est la demande qui me parait la plus justifiée. Vous le savez si vous avez déjà fait du OpenGL : il n’y a rien d’inclus de base pour le rendu du texte qui soit cross-platform. Pour éviter le problème, j’avais donc créé des images PNG avec mon texte que je chargeais comme textures. On m’a demandé de changer ça et on m’a suggéré d’utiliser la librairie QuesoGLC. Cette lib n’est pas très répandue et si vous n’utilisez pas Debian, vous n’avez probablement pas de package. Néanmoins cela fonctionne bien… sous Linux, car sous Windows cela plante systématiquement et pas moyen de la faire marcher. Au final je choisis donc de créer un ensemble de fonctions que j’appellerai de manière générique et qui sous Windows appelleront le système de rendu de texte intégré spécifique de l’OS, et qui sous Linux appelleront QuesoGLC. Au final cela fonctionne (après beaucoup de travail), et l’on ne voit aucune différence du point de vue utilisateur avec la version précédente (en fait le rendu est un peu moins bon sous Linux).

      Ensuite, il faudrait également que l’icône du logiciel (en 64x64 pixels), qui est une souris, soit générée à partir de l’image grand format utilisée dans le jeu, en utilisant ImageMagick pour la redimensionner à la compilation, plutôt que de fournir une icône 64x64 toute faite (on va sûrement économiser quelques centaines d’octets grâce à ça…).

      Ensuite, il y a une image PNG (celle de l’aigle) dont on devine qu’elle a été créée à partir d’une image vectorielle. C’est le cas, elle vient d’OpenClipart (domaine public) et j’avais ensuite modifié une version PNG avec GIMP (pour changer les couleurs). On me dit que je ne devrais pas fournir l’image PNG mais plutôt une version SVG qui serait transformée en PNG à la compilation. Cela ajoute donc une dépendance vers la librairie RSVG pour compiler mon jeu (pour générer 2 images au final). Quand je réponds que avec RSVG et ImageMagick on va ajouter plein de dépendances pour quelqu’un qui veut compiler mon jeu sous Linux et que ça va compliquer la vie de ceux qui veulent l’essayer on me répond de manière sarcastique que si je ne voulais pas qu’il y ait de dépendances, je n’ai qu’à inclure aussi X11 et le noyau Linux dans mon tar.gz. Au final je reprends l’image SVG de départ, refais avec Inkscape les modifications que j’avais originalement faites initialement sur le PNG directement, et j’inclus dans le Makefile l’appel à rsvg-convert. Pour la version Windows je n’ai aucune envie de faire une compilation si compliquée donc je garde l’image PNG initiale.

      Dans la liste des changements que j’ai le droit de remettre à une version ultérieure il y a la présence de caractères latin1 et non ASCII dans le code. En fait il s’agit uniquement du symbole copyright pour afficher en bas de l’écran d’accueil du jeu. Passer cela en UTF-8 nécessiterait de mettre du code non cross-platform car Windows et Linux gèrent cela différemment.

      Je serais aussi censé assurer la compatibilité avec SDL 2. En fait cela nécessite de réécrire des parties entières du code donc je n’ai aucune intention de le faire (à ce moment là SDL 2 n’était pas encore incluse dans une version stable ou testing de Debian).

      Au final MiceAmaze a été inclus dans Debian après 3 mois. Tous ces changements m’ont pris au total plusieurs jours de travail, mais qui n’ont du point de vue utilisateur produit aucune différence (même pas en termes de FPS plus élevées) à tel point que pour la version Windows j’avais laissé la version précédente car on ne voyait aucune différence. J’ai passé autant de temps à changer toutes ces choses là à l’époque qu’à améliorer le logiciel d’un point de vue fonctionnalités par la suite. Je n’ai pas eu le courage de recommencer tout ça, ce qui fait que la dernière version (3.0) n’est pas incluse dans Debian (qui a la 1.8). Mais je n’ai pas envie de doubler mon temps de travail à chaque fois que j’ajoute une fonctionnalité dans le logiciel, je préfère utiliser ce temps pour ajouter deux fois plus de fonctionnalités…

      Ma conclusion est que je vous décourage d’inclure vous-même un logiciel que vous avez créé dans Debian. Si vous packagez le logiciel de quelqu’un d’autre, on ne vous demandera pas de le modifier car vous n’êtes pas l’auteur. Inversement si vous êtes l’auteur, la personne qui le package ne vous demandera pas non plus de modifier votre logiciel (elle ne fait que le packager).

      NdM : l'auteur du journal nous a demandé le 29/10 d'ajouter ce correctif :

      La publication de cet article a entraîné une discussion avec les personnes concernées chez Debian. Il s’avère que beaucoup des demandes dont je parle n'étaient pas obligatoires. Cependant, le contexte m'avait laissé penser le contraire, il s'agit alors d'une erreur de ma part et je m'en excuse. Au final, cela ne devrait pas vous dissuader d'inclure vos logiciels dans Debian. Je compte pour ma part essayer d'inclure la dernière version de mon logiciel en prenant en compte ces nouvelles données.

      Lire les commentaires

    • Journée de test pour la Fedora 21 le 8 novembre 2014 à Paris (Dépêches LinuxFR)

      L'association Borsalinux organise samedi 8 novembre une journée de tests et de rapports de bugs de la version Bêta de Fedora 21, dans les locaux de Mozilla France à Paris (16bis Boulevard Montmartre), de 14 heures à 18 heures.

      Venez apprendre comment tester Fedora efficacement, comment rédiger un rapport de bug et plein d'autres choses.

      Pensez si possible à ramener un ordinateur avec vous et, encore mieux, avec une configuration exotique, en particulier une carte ARM. Des live-CD de Fedora 21 seront disponibles.

      L'entrée est libre, et accessible à tout public.

      Lire les commentaires

    • Quatre ans de projets libres : bilan et retour d'expérience (Journaux LinuxFR)

      Sommaire

      Et voilà  le 4ème post sur mon retour d'expérience de développeur de logiciels libres. Cela avait démarré il y a quatre ans avec Newebe un projet de réseau social distribué en Python. Au bout d'un an de code j'avais écrit un billet de blog pour faire le bilan de l'année écoulée autour de mon expérience de développeur libre (1). J'ai perpétué ce principe les deux années suivantes (2, 3). Entre temps j'ai démarré un autre projet beaucoup plus ambitieux nommé Cozy, un cloud personnel libre. Aujourd'hui je remets donc le couvert pour faire le bilan de mon année la plus active dans l'univers du logiciel libre.

      Ce que j'ai fait cette année

      Point de vue code, j'ai terminé et réalisé la nouvelle interface de Newebe et j'ai poussé les premiers commits d'une version Node.js de ce projet. J'ai fait l'effort de fournir de nombreux moyens de déploiement (paquet Debian, Dockerfile, recette Ansible, intégration au projet Sovereign). Toutefois j'ai avancé beaucoup plus lentement que les années précédentes. En effet, l'ensemble de mon temps s'est porté sur Cozy. C'est assez logique étant donné que c'est mon activité professionnelle et entrepreneuriale. Je suis intervenu sur l'ensemble de la plate-forme et de ses applications tant en développement qu'en facilitateur de communauté.
      Sur mon temps libre j'ai continué à  maintenir la lib request-json, un client HTTP adapté aux interfaces REST et JSON, KYou et Konnectors des applications Cozy de Quantified Self et j'ai démarré Cozy Light une version minimaliste de Cozy facile à déployer.
      Le projet entrepreneurial Cozy Cloud s'étant affirmé (nous sommes une équipe de développement constituée d'une petite dizaine de personnes), j'ai pu aussi constater l'impact du développement libre sur notre organisation.

      Développement

      Cette année j'ai pris mon rythme de croisière, je n'ai pas changé grand chose à  mon mode de développement. Les deux plus grosses modifications que j'ai faites sont un changement de thème de couleur vi et un test de ZSH (toujours en cours). Par contre, mes nouvelles facilités à  mettre en oeuvre un projet m'ont incité à  me disperser. Vouloir continuer à expérimenter tout en améliorant Cozy m'a poussé à coder beaucoup de choses rapidement. C'est une étape intéressante à traverser mais j'espère pouvoir me limiter sur la quantité de fonctionnalités produites en faveur de la qualité. J'aimerais pour l'année à  venir retourner à  une manière de coder plus patiente.
      Pour faire un parallèle, quand on fait de l'escalade on se rend compte qu'en prenant bien le temps de poser ses appuis on fournit beaucoup moins d'efforts pour atteindre l'étape suivante. Je trouve que pour le code les choses sont un peu pareilles. Pour bien avancer dans son programme il vaut mieux bien valider chaque étape. Sinon au milieu du parcours on se retrouve épuisé.

      Il faut savoir accepter qu'un projet est fini. J'entends par là  qu'il ne mérite plus que de la maintenance. En effet on a trop tendance à  vouloir toujours rajouter des fonctionnalités. Mais au bout d'un moment il faut simplement s'arrêter et se dire que le projet fait bien ce qu'il doit faire. Cet état est atteint pour request-json et Newebe s'en rapproche.

      Faire des choses simples c'est difficile. J'en ai pris pleinement conscience récemment lorsque j'ai développé Cozy Light, une version minimaliste de Cozy. Le code ne fait que 800 lignes contre des dizaines de milliers pour Cozy. On pourrait penser que coder Cozy Light est plus facile. Pourtant il m'aurait été impossible de le réaliser sans avoir travaillé sur la version complète.

      Le taureau par Picasso

      Pour illustrer je vais prendre la série de dessins suivants qui était distribuée aux employés d'Apple pour leur montrer le processus de simplification appliqué à  leurs produits. On voit avec le dernier dessin qu'on peut garder l'essence d'un dessin complexe en ne préservant que quelques lignes. Cette légèreté est particulièrement efficace en logicielle car elle permet d'arriver aux mêmes fins qu'un logiciel complexe avec une maintenance grandement amoindrie. Cet exemple est intéressant mais ce qu'on oublie souvent de dire à son propos, c'est que pour obtenir le dernier dessin, il a fallu être capable de dessiner le premier dans toute sa complexité.

      Point de vue des technos je suis beaucoup rester dans l'univers Javascript/Coffeescript au détriment de Python. Aujourd'hui les deux langages que je voudrais explorer sont Go et Lua. Go car il parait qu'il possède beaucoup de fonctionnalités facilitant la vie du développeur, ça doit donc être enrichissant à  utiliser. Lua m'attire de par ses caractéristiques de légèreté. En effet cette techno me semble bien adaptée à l'auto-hébergement .

      Je me sens plus à  l'aise avec l'éco-système Node.js, j'y participe plus. J'ai dû comprendre le fonctionnement de bibliothèques bas niveaux pour résoudre certains bugs. J'ai contribué à des bibliothèques réalisées par d'autres. J'ai même eu l'occasion de résoudre un bug en collaboration avec un autre contributeur que les principaux, c'était particulièrement enthousiasmant.

      De manière plus générale j'ai du ressortir mes livres de système pour bien comprendre comment ça fonctionnait en dessous. J'ai une meilleure compréhension de l'ensemble de l'environnement dans lequel évolue mes programmes.

      Enfin, je code plus vite. Je me pose beaucoup moins de questions quand je démarre un projet ou que je rajoute une fonctionnalité. Et ça c'est agréable !

      Entreprise

      Red Zone

      Le rapport du logiciel libre et de l'entreprise est particulier. Il bouscule les habitudes. Du point de vue financier, il pose la question de comment gagner de l'argent avec un produit que l'on peut acquérir sans payer. Du point de vue éthique, il pose la question de comment respecter les principes du logiciel libre avec une logique de croissance soutenue et permanente. Chez Cozy nous avons dû donc construire notre projet pour satisfaire les deux parties prenantes que sont nos financeurs et la communauté. Pour cela une logique basée sur la mutualisation de service et la licence AGPL ont été de bons outils. L'un nous ayant permis de justifier un besoin fort de services rémunérés autour de notre solution, l'autre en tant que garde fou au cas où nous ne respecterions plus la philosophie initiale du projet. Mais au final ce n'est pas surprenant que nous ayons réussi à  trouver une harmonie. Les licences libres sont des outils, leurs caractéristiques sont découplés des intentions.

      Faire du logiciel libre en entreprise m'a permis de m'entourer de gens compétents qui partagent les mêmes principes que moi. C'est assez agréable de se faire reprendre car il n'y a pas assez de tests sur tel module, d'avoir des collègues qui se posent des questions sur la pertinence de la longueur d'un sprint ou de soulever des débats intéressants sur tel choix de technologie. Sans parler de la veille permanente réalisée par le groupe qui fait que je n'ai plus tant besoin de me renseigner sur les dernières nouveautés.

      La logique collaborative favorise l'efficacité. D'une part la mise en commun des savoirs et des productions crée un cercle vertueux. D'autre part quand on est prêt pour accueillir de nouveaux contributeurs, on est prêt à recevoir un nouveau collaborateur à temps-plein. Enfin, les communications sont mieux organisées et tout est historisé.
      NB : Pour une entreprise où tout le monde est en télétravail, cela fonctionne d'autant mieux.

      Recevoir les retours et les contributions de la communauté est très efficace. Le regard neuf et extérieur des contributeurs nous permet de savoir plus facilement sur quels points se concentrer pour arriver à  un produit fini. C'est aussi très motivant de recevoir de l'aide de gens extérieurs.

      Les peer reviews sont bénéfiques. Chez Cozy nous les avons mises en place plus systématiquement et le gain en qualité s'en ressent vraiment. Autant je ne regrette pas qu'avant cela, nous n'en faisions pas plus (nous avions besoin d'aller vite, nous n'avions pas encore bien pris nos marques) autant aujourd'hui elles me paraissent très utiles étant donné la quantité de code que nous devons maintenir.

      Enfin j'ai pu défendre notre cause dans des endroits moins avertis (événements startups principalement). Toutefois je n'ai pas su le faire en employant le terme de logiciel libre. J'ai parlé de logiciels "open source".

      Et ensuite ?

      C'est tout pour cette année. Je n'ai pas évoqué les différents événements (JDLL, RMLL, OWF, etc..) auxquelles j'ai participé. Ils sont toujours aussi sympathiques et bouillonnants d'idées. Pour en revenir au code, je pense que pour l'année à  suivre je vais essayer de contribuer un peu plus à  des projets autres que les miens. J'espère également que la communauté Cozy va grandir suffisamment pour que nous ayons la possibilité de devoir mieux gérer les contributions extérieures et penser ainsi à un mode de gouvernance plus évolué. En somme, j'ai encore vécu une année pleines de découvertes et j'espère que l'année prochaine sera aussi palpitante !

      Lire les commentaires

    • Revue de presse de l'April pour la semaine 43 de l'année 2014 (Dépêches LinuxFR)

      La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

      Sommaire

      [Reporterre] Contre l'obsolescence informatique, vivent les logiciels libres!

      Par Camille Lecomte, le jeudi 23 octobre 2014. Extrait:

      En avril dernier, Microsoft a mis fin au support Windows XP, entraînant la fin prématurée de 500 millions d’ordinateurs qui en étaient équipés à travers le monde. Windows pense-t-il par cette décision nous imposer ses nouvelles machines? C’est sans compter sur les logiciels libres!

      Lien vers l'article original: http://www.reporterre.net/spip.php?article6472

      [Rue89] Internet terrorise les députés. Tous? Non…

      Par Camille Polloni, le jeudi 23 octobre 2014. Extrait:

      Ils sont déçus, mais prêts à recommencer quand il faudra (et ça ne manquera pas d’arriver). Pendant les débats sur la dernière loi antiterroriste, adoptée en commission mixte paritaire mardi, l’Assemblée nationale s’est transformée en théâtre de leur défaite.

      Lien vers l'article original: http://rue89.nouvelobs.com/2014/10/23/a-reuni-les-trois-deputes-cyberoptimistes-255632

      Et aussi:

      Voir aussi:

      [JDN] L’écosystème du logiciel libre en France face à trois grands défis

      Par Stéfane Fermigier, le jeudi 23 octobre 2014. Extrait:

      C’est en se regroupant au travers de structures (Clusters, Pôles de Compétitivité, etc) favorisant l'innovation ouverte, l'accès au marché, et la formation aux technologies de demain, que l’écosystème du logiciel libre en France pourra bénéficier des meilleures opportunités de création de valeur.

      Lien vers l'article original: http://www.journaldunet.com/solutions/expert/58876/l-ecosysteme-du-logiciel-libre-en-france-face-a-trois-grands-defis.shtml

      Et aussi:

      [Le Monde.fr] De l’utopie anti-Facebook au cyberdjihad, le destin contrarié du réseau social Diaspora

      Par Martin Untersinger, le mardi 21 octobre 2014. Extrait:

      Le réseau axé sur les droits des utilisateurs a connu une histoire mouvementée.

      Lien vers l'article original: http://www.lemonde.fr/pixels/article/2014/10/21/de-l-utopie-anti-facebook-au-cyberdjihad-le-destin-contrarie-du-reseau-social-diaspora_4504282_4408996.html

      Et aussi:

      [Numerama] Microsoft clame son amour pour Linux

      Par Julien L., le mardi 21 octobre 2014. Extrait:

      Lors d'une conférence sur Windows Azure, Microsoft a affiché son affection pour Linux, tranchant avec les vieilles controverses qui ont émaillé les relations entre la firme de Redmond et la communauté du logiciel libre. Mais cette déclaration n'est pas innocente: elle s'inscrit dans une évolution de fond de l'informatique grand public.

      Lien vers l'article original: http://www.numerama.com/magazine/31005-microsoft-clame-son-amour-pour-linux.html

      Et aussi:

      [Datanews.be] Le retour à Windows coûterait des millions à la ville de Munich

      Par Pieterjan Van Leemputten, le lundi 20 octobre 2014. Extrait:

      Si Munich en revenait effectivement à Windows au bout de dix ans, cela lui coûterait des millions d'euros supplémentaires.

      Lien vers l'article original: http://datanews.levif.be/ict/actualite/le-retour-a-windows-couterait-des-millions-a-la-ville-de-munich/article-normal-317265.html

      Et aussi:

      [Libération.fr] L'apprentissage en primaire du code informatique «dans l'année qui vient»

      Par Hugo Pascual, le dimanche 19 octobre 2014. Extrait:

      A l'occasion de la «code week», la ministre de l'Education, Najat Vallaud-Belkacem, et la secrétaire d’Etat chargée du numérique, Axelle Lemaire, ont visité une session d'initiation à la programmation pour enfants.

      Lien vers l'article original: http://www.liberation.fr/societe/2014/10/19/l-apprentissage-en-primaire-du-code-informatique-dans-l-annee-qui-vient_1122642

      Lire les commentaires

    • SUSE Linux Enterprise 12 disponible ! (Journaux LinuxFR)

      Certains attendaient cette nouvelle version depuis longtemps. Elle est enfin arrivée !

      SUSE Linux Enterprise Server 12 et SUSE Linux Enterprise Desktop 12 sont désormais disponibles en différentes déclinaisons :
      SLE 12

      Côté Serveur, SLES 12 est disponible sur architechture x86_64, Power Systems et System z (Mainframe). Parmi les nouveautés intéressantes :
      - Possibilité de mise à jour en live du noyau (kGraft)
      - System rollback
      - Prise en compte des nouvelles fonctionnalités MainFrame
      - Et bien sur, nouveaux noyaux, Glibc…

      Côté technique, quelques informations relatives au support mémoire, FS et autres :
      Technique

      Côté Desktop, SLED 12 n'embarque plus KDE mais se focalise sur Gnome. L'interface a été peaufinée mais les aficionados de KDE seront déçus.

      Côté administration licence, arrivée du nouveau SUSE Customer Center qui remplace l'immonde Novell Customer Center.

      SUSE est second sur le marché Linux, loin derrière Redhat qui a quasiment en situation de position dominante. SUSE se démarque sur les segments MainFrame et SAP, leader sur ces segments.

      Il est possible de télécharger SLES 12 ici et SLED 12 ici. Vous aurez droit à 60 jours maxi de mise à jour du système.

      Lire les commentaires

    • Dead Pixels Society (Journaux LinuxFR)

      Bonjour Nal,

      Dans la dernière dépêche d'une série que tu adores lire, j'avais évoqué la création d'un club de développement de jeu vidéo dans mon université. Voici quelques nouvelles !

      Le club marche plutôt bien. Au total, c'est une soixantaine d'étudiants qui participent toutes les semaines à travers 5 projets (ça représente environ 1/3 des promos à peu près). Il y a majoritairement des informaticiens mais également des étudiantes de psycho et de lettres. Il y a même une étudiante de psycho qui est responsable d'un des projets ! Les groupes font entre 10 et 20 personnes, ce qui fait beaucoup quand on n'a jamais eu l'habitude de travailler à plus de 2. C'est d'ailleurs le principal challenge de ces projets, beaucoup plus que les aspects techniques liés aux jeux vidéo. Ce qui explique qu'au bout de 2 mois, il n'y ait pas encore beaucoup de code commité sur les dépôts.

      Je vais vous présenter le projet dans lequel je suis impliqué, qui s'appelle Gzzzt. Au départ, je ne pensais pas qu'il y aurait beaucoup d'étudiants. Donc, je pensais pouvoir m'impliquer dans un projet. Mais au final, avec autant de projets, ce n'est pas forcément une bonne idée. Parce que tous les groupes ont besoin de conseils et d'aides, et malheureusement, comme je suis impliqué dans un groupe en particulier, je ne peux pas me consacrer aux autres autant que j'aimerais. Mais bref, voici le projet Gzzzt.

      Gzzzt est (ou sera) un clone de Bomberman/Dynablaster en réseau dans un univers de robots. Les traditionnelles bombes seront remplacées par des boules électriques (d'où le nom du jeu). Évidemment, à terme, on espère pouvoir mettre tous les bonus/malus bien connus de ce type de jeu, mais on en est encore loin. Une des difficultés du jeu est la partie réseau temps réel et plus particulièrement, c'est l'occasion de tester des techniques de prédictions côté client. Pour l'instant, un petit moteur physique basique a été développé, à partir d'une excellente série d'articles sur la création d'un moteur physique complet. Les articles sont très bien mais le code source donné en exemple est rempli de bugs très sévères. Heureusement, j'ai pu les identifier et les corriger et ça a l'air de fonctionner. J'ai aussi simplifié le moteur en enlevant les forces (inutiles dans le jeu pour l'instant) et en gardant uniquement la partie collision. La partie réseau est également en train d'être développée petit à petit. Côté technos, on a opté pour ce bon vieux C++/SFML, et les cartes seront définies grâce à Tiled.

      Pour la suite, on espère pouvoir avoir une version zéro à la mi-novembre. Le timing est très serré mais on a à peu près tous les éléments en place. J'essaierai de donner des nouvelles de temps en temps.

      Lire les commentaires

    • Journée du Libre (Ubuntu Party) le 29 novembre 2014 à Sarrebourg (Dépêches LinuxFR)

      Pour la septième année le club informatique du Centre Socio Culturel de Sarrebourg organise une journée de découverte des logiciels libres, le samedi 29 novembre de 10h à 17h, ouverte à tous.

      Divers stands vous proposeront de tester ou d'installer ces logiciels, de voir des imprimantes 3D libres en action, ou même de vous apprendre comment recycler de vieux PC.

      Vous trouverez le détail de cette journée en seconde partie de l'article.

      Vous retrouverez dans la grande salle :

      • des stands de démonstration : vous pourrez découvrir et tester vous-mêmes les logiciels libres sur des ordinateurs mis à votre disposition. Un stand sera consacré aux imprimantes 3D : vous pourrez voir en action cette innovation technologique dont on entend tant parler. Des bénévoles seront là pour vous guider et répondre à toutes vos questions.
      • un coin installation : si vous êtes conquis pas les logiciels libres, vous pourrez sauter le pas sur place et faire installer Linux sur votre ordinateur (il suffit de ramener votre portable ou la tour de votre ordinateur de bureau). Dans ce cas, sauvegardez vos données avant de venir et prenez les chargeurs & câbles d'alimentation avec vous.
      • un espace recyclage grâce aux logiciels libres : dans le cadre de la semaine européenne de réduction des déchets, l'association Ekosens montrera comment, grâce à des logiciels libres peu gourmands, il est possible de donner une seconde vie à de vieux ordinateurs aux ressources limitées. Une bourse de matériel informatique sera aussi mise en place : vous pourrez y déposer les matériels et composants fonctionnels dont vous n'avez plus usage ou y dénicher des pièces de rechange pour remettre à neuf certains de vos ordinateurs. Des réparations matérielles sur le stand d'Ekosens démontreront au cours de la journée qu'il n'est pas nécessaire de tout jeter à la première panne venue.
      • des panneaux explicatifs : des panneaux retraçant l'histoire du logiciel libre et ses grands principes vous permettront d'y voir plus clair. Les bénévoles qui animent cette journée pourront répondre à toutes vos questions sur le mouvement du libre.

      Deux ateliers pratiques et une conférence rythmeront la journée :

      • à 10h30 : atelier de découverte de Linux

      Quoi de mieux, pour découvrir ce qu'est vraiment Linux, que de l'essayer ? C'est l'ambition de cet atelier : vous permettre de tester vous-même, en toute confiance, le système d'exploitation Linux. Une visite guidée, en somme, destinée avant tout aux néophytes et aux curieux. L'atelier se terminera pour midi.

      • à 13h00 : atelier de retouches d'images avec The Gimp

      Dans cet atelier, vous apprendrez à retoucher vos photos à l'aide du logiciel libre The Gimp. Une bonne occasion pour apprendre à améliorer vos clichés et prendre en main cet outil puissant ! L'atelier se terminera avant 15 heures.

      • à 15h00 : une présentation de l'imprimante 3D

      Cette année, l'imprimante 3D sera mise à l'honneur. Chacun a entendu parler de cette avancée technologique à la télé ou ailleurs. Lors de cette journée, vous pourrez voir fonctionner, en direct, des imprimantes 3D libres. Leurs concepteurs seront là pour répondre à vos questions et proposeront, à 15 heures, une présentation de l'outil et de ses possibilités.

      Entrée Libre.

      Lieu : Centre socio-culturel, rue des Berrichons et Nivernais, Sarrebourg 57400.
      Informations

      Contact gorfou CHEZ mailoo POINT org

      Lire les commentaires

    • Enlightenment DR 0.19 et autres nouveautés éclairées (Dépêches LinuxFR)

      Alors que la version 0.17 d’enlightenment avait mis des années à pointer le bout de son nez, la version 0.19 de ce desktop shell (environnement de bureau) arrive moins d’un an après la version 0.18 !

      logo E

      Cette dépêche est aussi l’occasion de présenter l’actualité de projets associés, comme les bibliothèques EFL au cœur d’E, l’émulateur de terminal Terminology et le lecteur multimédia Rage dont la toute première version a été publiée cet été.

      Merci à Rolinh d’avoir initié et ainsi encouragé la rédaction de cette dépêche.

      Sommaire

      Enlightenment DR 0.19

      Enlightenment DR 0.19 a donc été publié le 15 septembre dernier, suivi d’une mise à jour mineure le 14 octobre.

      Enlightenment DR 0.19

      Enlightenment DR 0.19 et Wayland

      Cette version a été marquée par le travail de Chris “devilhorns” Michael qui a énormément amélioré le compositeur Wayland : l’empreinte mémoire a été réduite, la complexité du rendu a été simplifiée et le code lui-même est plus succinct. Le compositeur Wayland devient de plus en plus autonome.

      Du point de vue de la cohabitation X11/Wayland, une session X11 peut afficher des clients Wayland et X11 n’est plus nécessaire pour afficher des clients Wayland, par contre le compositeur Wayland ne prend pas encore en charge les applications X11 (beaucoup de travail doit être encore fait sur xwayland).

      On peut désormais forcer le rendu de Wayland avec la variable E_WL_FORCE : avec par exemple la valeur x11 pour lancer le compositeur Wayland imbriqué dans X11, drm pour un affichage via KMS ou encore fb pour le framebuffer.

      Enlightenment DR 0.19 et le reste

      La fiabilité de la prise en charge du multi-écran a été améliorée ainsi que la gestion du rétroéclairage. Les fenêtres non-rectangulaires sont mieux rendues et Enlightenment utilise désormais l’extension XPRESENT de X11 qui permet de réduire la charge de composition lorsqu’un bitmap change de taille.

      Gstreamer 1.0 est désormais utilisé pour la prévisualisation multimédia et cette prévisualisation indique la résolution de la vidéo. Le système de verrouillage d’écran peut être déverrouillé avec une interface façon « code pin », très utile sur les périphériques mobiles.

      Enlightenment propose désormais un profil pavant pour son gestionnaire de fenêtre.

      Enlightenment DR 0.19, Tiling Profile

      Pour ceux qui aiment, un pager (fenêtre qui montre un aperçu réduit et dynamique de tout l’écran) à la manière du vénérable E16 est désormais disponible. Dernière nouveauté qui est surtout utile pour les testeurs, il est désormais possible d’utiliser la variable d’environnement E_MODULE_SRC_PATH pour charger des modules qui ne sont pas installés dans l’arborescence par défaut.

      Enlightenment a été traduit dans une vingtaine de langues.

      Terminology 0.7

      Terminology 0.7 est sorti quelques temps après Enlightenment DR 0.19, le 12 octobre 2014. Terminology est l’émulateur de terminal d’E, et cette version apporte des raccourcis clavier configurables, la possibilité de configurer la transparence, l’utilisation d’une police vectorielle par défaut, et la prise en charge de la localisation et de l’internationalisation.

      Terminology 0.7, Internalisation, Localisation

      On peut désormais lancer Terminology avec l’option -s ou --split pour découper la fenêtre en plusieurs terminaux dès le démarrage.

      Les contrôles multimédia ont étés améliorés (car oui, Terminology sait afficher du contenu multimédia directement dans le terminal), et dans la MiniVue, un indicateur signale désormais votre position courante dans l’historique. La MiniVue est un aperçu visuel de l’ensemble de l’historique qui peut être affiché sur le coté de la fenêtre, et il suffit de cliquer dessus à un endroit voulu pour se rendre directement à une partie intéressante.

      Terminology 0.7, Media, MiniView

      Rage 0.1

      Un peu avant la sortie d’Enlightenment DR 0.19 était sortie la toute première version du lecteur multimédia Rage. Si cette publication est restée confidentielle, on ne peut pas ne pas évoquer cette étape très importante pour ce projet.

      Rage 0.1

      C’est lecteur vidéo et audio qui se veut simple et dépouillé, un peu comme MPV. Il suffit de passer un ou plusieurs fichiers en paramètre de la ligne de commande ou de les glisser-déposer directement sur la fenêtre pour les ajouter à la liste de lecture. Un aperçu de la liste de lecture peut être affichée à droite de la fenêtre et un aperçu de la vidéo est donnée au survol de la barre de progression de lecture.

      Rage prend en charge Gstreamer 0.10, Gstreamer 1, Xine et VLC comme moteur multimédia via des modules Emotion.

      Rage utilise le moteur Evas et bénéficie ainsi d’une accélération OpenGL optionnelle, et la possibilité de s’afficher dans X11, Wayland, ou directement sur le Frambuffer. Le déplacement dans le flux multimédia peut être contrôlé avec des gestes.

      EFL et Elementary 1.11.3, Python-EFL 1.11

      Cela concerne surtout les développeurs, le 14 octobre ont été publiées des mises à jour des EFL avec de nombreuses corrections, ainsi qu’une nouvelle version d’Elementary, un toolkit simple fondé sur les EFL.

      Les EFL (pour Enlightenment Foundation Library) sont un ensemble de bibliothèques au cœur du projet E : types, objets, parseur binaire et sérialiseur, opérations d’entrées/sorties asynchrones, gestion du matériel, abstraction du système d’exploitation, intégration de d-bus et des stantards xdg pour les menus et les icônes, canvas de dessin, moteur physique, interface multimédia, génération de miniature, etc.

      De son côté, l’interface Python-EFL a été publiée en version 1.11.0 le 14 septembre 2014. Cette nouvelle version apporte de très nombreuses corrections, mais il faut noter que la prise en charge des versions pre-1.8 de EFL et Elementary a été abandonnée.

      Lire les commentaires

    • Conférence d'Andrew S. Tanenbaum (Journaux LinuxFR)

      Andrew S. Tanenbaum, créateur de Minix, un OS à micro-noyau qui a été une des sources d'inspiration de Linux, viendra parler de Minix 3 mardi 28 Octobre 2014 à Jussieu à 18h dans l'amphi 24.

      La conférence a lieu dans le cadre du colloquium d'informatique de l'UPMC, série de conférences auxquelles ont déjà participé, entre autres sommités de l'informatique, Donald Knuth, Leslie Lamport, Robert Sedgewick, ou Tony Hoare.

      Vous aurez l'occasion de demander à Tanenbaum si Linux est obsolète, comme il l'affirmait en 1992, ou plus sérieusement, de discuter des mérites comparés des micro-noyaux et des noyaux monolithiques.

      But in all honesty, I would suggest that people who want a MODERN "free" OS look around for a
      microkernel-based, portable OS, like maybe GNU or something like that.

      (Hé oui, le développement de GNU/Hurd a commencé en 1990, deux ans avant ce message sur comp.os.minix  !)

      Lire les commentaires

    • Ruby Terminal session 3, le 28 octobre 2014 à St-Étienne (Dépêches LinuxFR)

      L’écriture d’un logiciel c'est un peu comme des nains qui creusent une mine…. On sait quand ça commence, pas quand ça finit.

      L'atelier Terminal Ruby porte bien son nom, c’est une hérésie rien que dans le titre. À travers les ateliers Terminal Ruby, nous vous proposons de nous attarder sur le plaisir d'écrire, la découverte d'un langage, ses subtilités ou ses multiples variations de tests de réponses autour d'un besoin donné.

      Résumé de l'épisode précédent et programme du suivant en seconde partie de la dépêche. Pour la session 3 à venir, voir l'article sur le site d'alolise, ce sera le 28 octobre vers 19h15, jusqu'à 21h, à Saint-Étienne.

      Résumé de l’épisode précédent:

      Le cours a commencé vers 19h et s'est terminé vers 21h, mais on ne savait pas ce qu’il y aurait dedans ⦿.⦿. Lire les commits du 21 octobre 2014.

      On est parti sur un bout de code grand débutant, tendance Perl, :) puis expérimenté la ré-écriture de code, le fameux refactoring avec la technique extract_method notamment, parce que c’est la préférée de l'animateur. Le tout en ping-pong de commit, mode pair-programming (git pull/git push), parce que sur un code de noob on ne peut pas faire des trucs de ouf, non plus… :)

      Au final je ne sais toujours pas ce que font certaines parties de ce code… Mais ça fait rien, qu’importe le pull request pourvu que…

      Bref, prochaine session :

      • davantage de refactoring
      • davantage de helloworld
      • les outils de remote : encore en recherche/test
      • et un peu de structuration dans le github parce que là, il faut ranger un peu :)

      Lire les commentaires

    • Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance (Journaux LinuxFR)

      Salut,

      je dois, pour des raisons de consommation, remplacer le (petit) cluster du boulot. Pour information, nous faisons du traitement scientifique d’images satellites. Nous avons besoin de puissance de calcul et d’I/O (aussi rapide que possible).
      Actuellement, on a 6 nœuds + un maître. 46 cœurs, 2 à 3.5go par cœur, 72 disques (12 à 24 disques par machine), pour un espace total de 140to (70 réellement utilisables avec la solution actuelle).
      Logiciellement parlant, on a:
      HTCondor pour la répartition des tâches.
      MooseFS pour le FS réparti (dont la version 1 n’est plus maintenue, la 2 n’est plus libre).
      Ganglia surveille le tout.
      Rien™ ne se charge de la configuration des machines sinon mes petits doigts.
      Le tout sur une plate-forme CentOS 6 x86_64.

      Je dois, si possible avoir mieux, tout en consommant (bcp) moins, le tout sans éclater le petit budget d’environ 20k€ HT.

      J’ai trouvé 3 solutions matérielles qui semblent correspondre (je mets les liens vers là où on achète nos bécanes habituellement, si vous connaissez mieux, ça m’intéresse, nous ne sommes liés en rien à la boite en question).

      1. Une grosse babasse gavée de CPU et de disques. 1800W, 4U. 18k€. 48 cœurs opteron 6xxx, 256 go (max) de ram (5.3go/cœur), 24 disques 6to. Le gros inconvénient, si la machine lâche, on a plus aucun moyen de production, ni d’accès aux données.
      2. Un Power Cloud R3PCA12-24, 1620W, 3U, 20k€. 96 cœurs opteron 3380 en 12 servers, 32 go (max) soit 4go/cœur, 2 disques par serveur soit 24 total (6to toujours). Beaucoup de CPU même si ce ne sont pas les plus rapides du monde, un déséquilibre cpu/disques qui me fait craindre un côté I/O surchargé et donc lent. Par contre, si une machine tombe, on ne perd que deux disques ce qui risque d’être peu problématique côté système de fichier réparti pour la disponibilité des données. Machines « maxées » (impossible d’ajouter plus de cpu ou de ram).
      3. Un FatTwin 12 disquse. 1620W, 4U, 23k€. 48 cœurs physiques/96 HT (intel xeon E5 2620v2) en 4 serveurs, 64 go (5.3 go/cœur), 256 max, 12 disques par serveur, 48 disques total. J’aime l’équilibre un disque/un cœur. J’aime beaucoup moins la chute d’une machine qui fait forcément que le FS réparti tombe avec (je ne connais pas de solution qui supporte à coût décent qu’un quart du volume disparaisse). La machine (à grands renforts de brouzoufs, intel n’y va vraiment pas avec le dos de la cuillère) peut évoluer en nombre de cpu (96 cœurs physiques max total) et en ram.

      Côté logiciel:
      1. On garderait HTCondor qui fait bien son travail.
      2. MooseFS est remplacé par une solution utilisant l’Erasure Code. Contrairement à MooseFS dont le coût est de 2 (réplicas) pour assurer un minimum de sécurité des données, cette technique permet un coût de 1.5 (je simplifie, pas la même de tergiverser). Je pense utiliser RozoFS, mais rien n’est gravé dans le marbre.
      3. Ganglia pourrait bien rester, HTCondor s’y intégrant bien (en théorie, j’ai pas eu le temps de faire la conf).
      4. J’hésite à mettre en place une solution type Ansible/Salt/Chef/Puppet bien que je les trouve assez overkill pour si peu de machines. J’aimerais trouver plus simple/plus rapide à déployer. et tant qu’à faire y intégrer les desktops utilisateurs (CentOS) ainsi que notre malheureux serveur web/bdd. soit 7 machines utilisateur (dont un windows), les serveurs au nombre de x + la gateway + le serveur web/bdd + le failover.
      Je passerais, dans la foulée, les machines utilisateurs/serveurs à CentOS 7.

      Voilà pour le topo. Merci pour vos lumières, je reste terriblement indécis. Le FatTwin me fait de l’œil, mais niveau HA c’est pas génial. Le microcloud me fait de l’œil, mais niveau I/O, c’est pas génial. Quelqu’un connaitrait-il une solution entre les deux ?
      Pour le côté résistance, j’aime bien AMD…et quand je vois les prix Intel…bref.
      Merci d’avance pour vos conseils et propositions. (inutile d’essayer de me « vendre » du debian ou ubuntu ou suse ou que sais-je. l’OS utilisé n’est pas en cause, merci :))

      Lire les commentaires

    • QRaidCODE, stocker des données sécurisée sur qrcodes (Journaux LinuxFR)

      Il y a un peu plus d'un an de ça, j'ai travaillé sur une application web de stockage de données sur qrcode utilisant un système proche du Raid des disques dur permettant de proposer à l'utilisateur de stocker des données sur une série de qrcode et de pouvoir n'utiliser qu'une fraction de ces qrcodes pour récupéré ses données.

      À l'époque, il s'agissait d'une application web qu'il était compliqué de déployer car nécessitant quelques binaires et notamment une version patché de zbarimg, j'avais l'idée de porter l'application en nodejs et faire une interface avec nodewebkit, mais je n'ai pas trouvé le temps et la motivation.

      Malgré ma fainéantise, docker me permet aujourd'hui de distribuer une version libre et fonctionnelle de l'application et de la proposer à tout un chacun pour jouer avec.

      La genèse du projet était de trouver un moyen de stocker des données importante sur le long terme comme un portefeuille de cryptomonnaie, une clé privé, etc, de permettre de distribuer le stockage des données entre plusieurs lieux ou personnes et de pouvoir récupérer ces données après une longue période de temps alors même qu'une fraction des qrcodes aurait été perdue. Les données sont chiffrées sur les qrcodes et il n'est pas possible d'accéder partiellement aux données avec un seul qrcode.

      D'un point de vu technique, il s'agit des mêmes algorithmes mis en œuvre dans le RAID 6, à savoir Reed-solomon, le développement de ce projet m'a été très formateur d'un point de vu mathématique, les corps de Galois utilisés pour calculer les données de parités ont des propriétés étonnantes.

      L'implémentation d'origine en PHP est disponible sur github, le projet est lourd car il est livré avec des matrices pré-calculées afin d'accélérer le codage et le décodage des données. Le Dockerfile est également disponible sur github et un container précompilé de l'application sur le hub docker.

      Il existe quelques limitations actuellement, il n'est pas possible de créer plus de 256 qrcodes (255 dans l'implémentation actuelle, un bug dont je n'ai pas identifié l'origine se produit lorsque l'on cherche à décoder 256 qrcodes), et la taille des données que l'on peut stocker au maximum n'est pas très importante (740 096 octets sans parités), une version permettant d'aller jusqu'à 65 536 qrcodes est définit mais pas encore implémentée (les matrices nécessaires au calcul prendrait plus de 4Go de ram et le temps de calcul pourrait être très important, limitant sont intérêt). Le format est spécifié sur le billet que j'avais publié l'année dernière.

      Il existe une démo sur un serveur pas très costaux avec un certificat auto-signé (ne pas l'utiliser avec des données sensibles).

      Si vous décidez d'héberger une instance derrière un proxy inverse, prenez garde au timeout qui peuvent se produire lors de la manipulation d'un nombre important de qrcodes.

      La licence du projet est la MIT licence. Toutes les contributions et commentaires sont les bienvenues bien entendu :)

      Lire les commentaires

    • Hack.lu 2014 (Journaux LinuxFR)

      Cher journal,

      Hack.lu, c'est fini, c'était la semaine passée. Alors, je vais te faire un résumé rapide des conférences que j'ai ou dont j'ai entendu parlées qui étaient particulièrement intéressantes. Vous pouvez retrouver une partie des supports de présentation dans les archives, elles n'étaient cependant pas filmées. Je ne vais pas détailler plus que ça parce que je n'ai pas forcément vu les conférences et puis, avec Google et le titre, vous trouverez plein d'informations si le sujet vous intéresse, si vous avez des questions, n'hésitez pas à utiliser le bouton carré avec écrit « Envoyer un commentaire ». Premièrement, les lightning talks de mardi. Elles commencent avec une démonstration par Philippe Teuwen pour montrer, à ceux qui en doutait encore, que le chiffrement ECB ne cache pas grand chose et que le CBC n'est pas forcément sûr non plus. Ensuite une démonstration d'Axelle Apvrille pour cacher un apk dans une image (développé avec Ange Albertini) et contourner ainsi beaucoup de systèmes de détection.

      La première conférence de mardi était faite par Filippo Valsorda qui a développé l'outil de test d'Heartbleed juste pour tester et qui s'est retrouvé submergé par les requêtes qui ne faisaient qu'augmenter au cours du temps. Il a notamment évoquer les extensions des navigateurs qui testaient les site pour vérifier s'ils étaient impactées qui, au final, lui envoyaient toute l'historique de navigation de ceux qui l'avaient installé. Ensuite, une explication sur le fonctionnement de l'application Android FinFisher par Attila Marosi, si jamais vous êtes infecté, vous pourrez la reconfigurer pour qu'elle s'autodétruise et être tranquille. Paul Jung nous a ensuite montré comment détecter l'exécution dans une machine virtuelle ou une sanbox, très utile si vous écrivez un malware ;) La conclusion est que pour éviter les virus, il vaut mieux avoir son système qui tourne en permanence dans ces environnement. Serge "sans paille" Guelton nous a parlé d'obfuscation de code Python. L'obfuscation de source n'est pas très utile dans ce langage, par contre, il existe d'autre technique pour éviter qu'on ne lise votre code trop simplement. La plus simple/efficace est de livrer un interpréteur modifié. Enfin, la journée s'est terminée avec une (longue) conférence de Xeno Kovah du MITRE explicant comment faire tourner un code en infectant l'UEFI et ayant le contrôle sur tout le système. L'exemple donnée est un programme qui scanne la mémoire en permanence à la recherche d'une signature particulière et qui exécute le code suivant cette signature. Cela veut dire qu'avec cela actif, il vous suffit d'un simple ping pour briquer le PC cible.

      Dans les lightning talks du mercredi, j'ai retenu celle de Philippe Teuwen sur les élection électronique belges, quelle était le bug et le portage sous Linux du système de vote pour le vérifier. Serge Guelton nous a encore parler d'obfuscation, il s'agissait ici d'une démonstration d'Epona, un outil de d'obfuscation basé sur LLVM. Il parait aussi que la conférence sur TR-069 était intéressante. Il s'agit un protocole utilisés par les routeurs domestiques (les box des FAI) pour se mettre à jour. Beaucoup d'implémentations sont très mauvaise au point de vue de la sécurité et il facile de pousser un firmware personnel sans accès physique. Xeno Kovah est aussi revenu pour nous parler de la suite la veille, et comment éviter la détection d'un BIOS modifié et comment éviter l'évitage de détection et… j'ai fais un stack overflow :). Au final, vos PC sont destinés à être hacké et vous ne pouvez pas faire grand chose pour contrer cela. La journée s'est terminée avec la fragmentation des paquets IPv6 et comment l'utiliser pour contourner les IDS (slides) par Enno Rey, les failles ont été rapportés aux différents dévelopeurs de ceux, mais comme chez Sourcefire, ils étaient trop occupés à compter leur stock options, plutôt qu'à répondre aux failles de sécurité, on a pu assisté à un beau 0day en direct. La conclusion est que les RFC sur IPv6 sont beaucoup trop bordéliques laxistes pour avoir une pile sûre (ou même respectant la norme).

      Je n'ai pas assisté aux conférences du jeudi mais il y en avait une sur Virtualbox et comment utiliser les instructions 3D pour en sortir des machines virtuelles. Saumil Shah a aussi jouer avec les images et a montré des exemples d'images qui sont aussi un fichier JavaScript valide ou même un JPEG qui est aussi du HTML et du JavaScript, une catastrophe pour la détection de comportement anormaux et le forensic d'une attaque.

      Je sais c'est un peu décousu mais moi je vous retranscris ça pèle-mêle aussi.

      Lire les commentaires

    • rv/hervé : recherche d’itinéraire vélo minimisant l'énergie en utilisant les données d'OSM (Journaux LinuxFR)

      Sommaire

      Introduction

      Il y a quelques temps, plus d'un an déjà, j'ai écrit un journal ici-même présentant un projet sur lequel je passais une partie de mon temps libre. Les choses ayant légèrement évolué depuis, je récidive. Bien que la lecture du précédent journal soit utile, elle n'est pas obligatoire pour comprendre celui-ci, sauf pour des points de détails, j'y ferai référence en temps voulu.

      Étant adepte du vélocipède en tant que moyen de transport, et comme tous les amateurs de cet activité merveilleuse, je suis régulièrement confronté à un problème de choix d'itinéraire. N'ayant qu'un amour modéré pour les côtes, et une haine, qui n'a d'égal que ma haine du café américain, pour les dépenses inutiles, comme par exemple monter pour redescendre alors qu'un détour minime permet d'éviter cette aberration, un choix de l'itinéraire basé uniquement sur la distance me paraît une absurdité comparable à celle d’apprécier la poutine.

      Il y a donc quelques années, mon Dieu que le temps passe vite, je me suis donc mis en tête de créer mon propre moteur de recherche d'itinéraire adapté à mes contraintes. Il est bien connu qu'on n'est servi de manière satisfaisante que par soi-même. En fait j'ai donc commencé à explorer, jouer avec les données, écrire du code, pour enfin obtenir un moteur de routage fonctionnel il y a environ un an et demi. Ce fut l'objet de mon précédent journal, et les choses ont peu évolué au niveau de ce moteur, principalement de la correction de bugs, un peu de réorganisation, et quelques nouvelles fonctionnalités. Rien de bien important. Puis n'ayant pas réussi à recruter de développeur de frontend, j'ai écrit une interface minimaliste et moche, pour montrer les possibilités du moteur.

      Je vais donc présenter, ici, de manière détaillée, mon moteur de routage, l'interface minimaliste et moche, et surtout lancer un appel à développeurs pour une interface non minimaliste et potentiellement non moche. Puis je vous présenterai les futures améliorations que je prévois d'apporter au moteur de routage, dans un avenir proche à lointain.

      rv, le moteur de routage

      Le moteur de routage se nomme rv. La seule raison profonde à ce nommage est mon incapacité à trouver des noms intéressants à mes projets. J'ai donc commencé par nommer mon dossier où je codais routage_velo, mais comme c'était trop long, je l'ai par la suite raccourci en rv. Le code du moteur de routage est disponible sur mon répo git. Si vous n'êtes intéressé que par l'utilisation du moteur de routage ou que par l’interfaçage, je vous conseille de sauter cette partie.

      Données

      Présentation des données

      Pour faire du routage, il me faut des données. Ainsi j'utilise deux types de données. Le premier est constitué de données cartographiques, instrument indispensable à du routage sur une carte. Je ne vous ferai pas l'affront de vous présenter de manière détaillée, en particulier parce que j'en suis incapable, le projet OpenStreetMap, dont l'objectif principal est de fournir une cartographie mondiale sous licence libre ODbL.

      Le second type de données est constitué des données altimétriques, puisque pour faire un routage en fonction de l'altitude, il me faut des données cartographiques avec des étiquettes altimétriques sur les points, informations que OpenStreetMap ne fournit pas. Pour ce faire j'utilise les données du projet SRTM de la NASA qui fournit pour l'ensemble du globe entre 60° et -60° de latitude des données altimétriques avec une précision au mètre suivant une grille de 3 secondes d'angle.

      Travail sur les données

      J'importe les données dans une base de donnée PostgreSQL avec les extensions PostGIS. Pour l'import des données cartographiques, j'utilise l'outil Osmosis, bien connu des utilisateurs d'OSM, et le schéma de base utilisé est pgsnapshot, tel que définit par Osmosis.

      Seules les données concernant des routes utilisables par les vélocipèdistes sont recopiées dans des tables personnelles, les tables du schéma pgsnapshot étant laissées intactes. En particulier, cela signifie que le moteur de routage peut cohabiter sur une même base de données utilisant le schéma pgsnapshot.

      J'importe également les données SRTM dans la base de données via un programme perso (fournit dans mon répo git). Certaines données sont manquantes (c'est assez rare), pour compléter les points manquants de la grille, j'utilise un algorithme des plus proches voisins une fois que ma grille est complète, je calcule l'altitude des nœuds fournit par OpenStreetMap via une interpolation bilinéaire. Cette étape est entièrement réalisée à l'aide de procédures postgres (plpgsql et plperl).

      La difficulté suivante sur les données se situe au niveau de la connexité. En effet, le graphe routier est constitué de plusieurs composantes connexes. Si certaines sont légitimes (comme celles représentant des îles non reliées au continent), certaines ne le sont pas (un parking que l'on a oublié de relier au monde extérieur). Il se trouve que si un utilisateur demande un routage entre deux composante connexe, celui-ci ne peut aboutir, et conduit l'algorithme, si il ne le sait pas, à explorer tout le graphe, ce qui est énorme et inutile. Ainsi les composantes connexes sont calculés et les nœuds sont étiquetés en fonction de leur composante connexe d'appartenance. Ainsi quand un utilisateur demande un routage entre deux points géographique, l'algorithme peut essayer de choisir les nœuds de départ et d'arrivée de telle sorte qu'ils soient sur la même composante connexe (dans l'exemple du parking, on projettera sur la route adjacente) si possible, et échouer avec un message d'erreur immédiatement si ça ne l'est pas (dans le cas d'un routage entre une île isolée et le continent par exemple). Ce calcul est entièrement effectué à l'aide d'une procédure postgres en plpgsql lors de l'import ou de la mise à jour des tables utilisées par le moteur de routage.

      Routage

      L'idée du routage est de minimiser un critère. Pour ce faire trois critères sont proposés :

      • Distance parcouru par le vélocipède

      • Dénivelé positif cumulé sur le trajet

      • Énergie dépensée par le vélocipédiste.

      Si vous avez bien suivi mon raisonnement et mon objectif, vous comprendrez que seul le troisième critère m'intéresse, le premier étant l'équivalent d'un routage bête et méchant, ne prenant pas en compte l'altitude, et le second correspondant à une recherche à tout prix d'évitement des côtes, même si cela implique un détour complètement absurde. Seul l'énergie dépensée par le cycliste prends en compte l'altitude et la distance parcourue, c'est un vrai compromis. Nous le savons tous, la solution se situe toujours dans le compromis, sauf vis-à-vis de la sanction appropriée concernant les amateurs de poutine.

      Toutefois j'ai implémenté dans mon routeur de routage les trois critères, principalement car cela permet de comparer le critère que je propose aux critères simplistes communément acceptés, et aussi car cela se faisait à moindre coût dans l'architecture du code. Dans la suite, je ne vais toutefois détailler que le modèle lié à l'énergie, le calcul de la distance ou du dénivelé positif ne nécessitant pas d'explications.

      Modèle physique pour le calcul de l'énergie

      Pour calculer l'énergie dépensée sur un trajet, j'ai utilisé un modèle physique, et j'ai utilisé les loi de la mécanique (du point). Il y a certaines hypothèses qu'il est nécessaire d'expliquer. Pour une vision en détail du modèle je vous conseille la lecture de mon précédent journal. Les hypothèses principales sont les suivantes.

      • L'animal fournit une puissance constante. Je considère que le cycliste sait se servir de ses vitesses, et les utilise de manière à fournir une puissance constante, que ça soit en côte ou en descente.

      • L'ensemble du cavalier et de sa monture est soumis à la pesanteur. C'est très important, c'est ce qui va faire varier l'énergie totale en fonction du relief.

      • Le cycle, et l'imbécile flanqué dessus, sont soumis à une résistance de l'air. La résistance est proportionnelle au carré de la vitesse relative par rapport à l'air. Vous pouvez trouver des infos sympa sur ce type de résistance ici.

      • Le vélocipède est soumis à une résistance au roulement. Cela provient de la déformation des pneus sur le sol. Cela dépend du type de sol, du type de pneu. Toutes choses égales par ailleurs, cette résistance est considérée comme proportionnelle au poids (je parle bien du poids de l'ensemble et non de la masse).

      • Il n'y a aucune perte d'énergie dans les virages. Cette hypothèse est fausse dans le cas où le cycliste est obligé de freiner à cause du rayon de courbure trop faible du virage par rapport à sa vitesse. Toutefois, c'est une hypothèse très utile pour le calcul.

      • Il n'y a aucun arrêt. Ce qu'il faut comprendre c'est que le cycliste ne s'arrête ni au feu, ni au stop.

      Certaines hypothèses peuvent paraître osées, c'est vrai, mais il faut dire qu'elles n'ont que peu d'influence sur le résultat final.

      Pour valider les hypothèses de résistance de l'air et résistance au roulement, j'ai fait des essais en descente avec un traceur GPS sur ma bicyclette sans fournir de puissance, et je peux affirmer avec confiance que ces hypothèses sont justifiées.

      Le modèle a donc plusieurs paramètres qui sont :

      • La masse roulante (bicyclette, animal, fret), elle influe sur l'inertie de l'ensemble en mouvement, sur le poids, et sur la résistance au roulement.

      • La vitesse sur le plat (qui, connaissant les autres paramètres sert à calculer la puissance constante à considérer)

      • La surface apparente et le coefficient de pénétration dans l'air (S.Cx) qui permet de calculer la résistance de l'air. Ce paramètre dépend principalement de la position du sportif sur son instrument de torture, mais peut aussi dépendre d'éléments extérieurs comme les sacoches ou un carénage tel qu'on voit dans les contre-la-montre.

      • Le coefficient de roulement. Il permet de calculer la résistance au roulement. Ce paramètre dépend principalement du type de pneu utilisé et du gonflage. Il est aussi influencé par le type de sol, mais il est supposé constant sur tout le trajet.

      • Le vent additionnel (vitesse et direction). À la discrétion de l'utilisateur pour prendre en compte un vent permanent et orienté dans le calcul du routage. Son influence est forte sur la valeur de l’énergie, mais faible sur le choix de l'itinéraire.

      Algorithme de routage

      Pour effectuer le routage dans un graphe, la première chose à quoi nous pensons est l'algorithme de Dijkstra. Toutefois cet algorithme est clairement lent, et je lui ai donc préféré l'algorithme A*, outre le fait d'être plus rapide, et d'être plus facile à orthographier, sous certaines conditions, l'algorithme A* est optimal de la même manière que l'algorithme de Dijkstra l'est.

      Pour résumer, l'algorithme A* et l'algorithme de Dijkstra consistent à explorer les voisins des nœuds connus en partant du nœud de départ. La différence c'est que l'algorithme A* va utiliser une heuristique qui estime le critère entre le nœud courant et le nœud d'arrivée pour choisir l'ordre d'exploration, et s'arrêter quand il aura exploré le nœud d'arrivé. Dans le cas général l'algorithme A* ne donne pas le résultat optimal. Toutefois si l'heuristique utilisée est admissible, c'est à dire si elle est une borne inférieur du critère, alors l'algorithme A* est optimal. Attention toutefois à avoir une heuristique informative, par exemple, prendre comme heuristique une fonction qui nous retourne 0, nous donne une heuristique admissible, mais dans ce cas cela revient à utiliser un algorithme de Dijkstra (à tous les niveaux dont au niveau temps).

      Dans mon cas, on peut pour chacun des critères avoir une heuristique admissible (et informative). Dans le cas de la distance, la distance à vol d'oiseau à l'arrivée est une minoration de la distance sur le graphe. Dans le cas du dénivelé positif cumulé, la partie positive de la différence d'altitude à l'arrivée est une minoration du critère (mais guère informative dans nombre de cas il faut l'avouer). Dans le cas de l’énergie, l’énergie dépensée sur un trajet en ligne droite à pente constante à l'arrivée sans prendre en compte la résistance de l'air (qui dépend de la vitesse que l'ont ne peut pas minorer, excepté par 0), est une minoration du critère.

      Au final, j'ai donc un algorithme, pas trop lent, et exact, pour choisir un itinéraire.

      Programme

      Le programme de routage est écrit en C++. Il fonctionne bien sous GNU/Linux. Il n'a pas été testé sur d'autres plate-formes.

      Pour lancer le routage, il faut écrire dans la base de donnée les paramètres, les points de départ, d'arrivé et les points de passage. Un job id est attribué par la base. Il faut ensuite lancer l'exécutable avec comme argument la chaîne de connexion à la base et le job id. Le programme lit les paramètres, lance l'algorithme de routage, écrit au fur et à mesure dans la base une estimation de l'avancement (ce n'est qu'une estimation, il n'est pas possible de prévoir le nombre de nœuds à parcourir à l'avance) et quand il a terminé écrit dans la base le résultat et termine.

      Dans les versions précédentes, il prenait ses arguments sur l'entrée standard et retournait avancement et résultat sur sa sortie standard, ceci a été modifié afin de permettre facilement un interfaçage à l'aide de scripts python.

      Interface web

      C'est là où les choses se gâtent. J'ai été pendant quelques temps satisfait de mon programme de routage, qui s'utilisait en ligne de commande. Même si guère pratique, ceci était suffisant pour mon usage, il apparaissait de manière assez évidente que ceci n'était pas satisfaisant pour l'usage général des utilisateurs de bicyclette.

      Non que j'accuse les vélocipèdistes d'être bêtes, même personnellement si j'affectionne les programmes en ligne de commande, il faut avouer que pour un usage cartographique, la ligne de commande ne semble pas ce qu'il y a de plus approprié.

      J'ai donc envisagé de greffer une interface au moteur de routage rv. Le fait que le moteur de routage demande d'avoir de manière accessible une base de données, implique qu'il est difficile de faire une interface sur un poste client pour un usage autonome, à moins d'installer en même temps la base de données et d'importer toutes les données nécessaires au routage. Il semble donc immédiat qu'une interface web est la solution adaptée, même si à titre personnel je ne suis pas satisfait du fait que de plus en plus d'outils se déplacent vers le web, induisant ainsi une dépendance et une difficulté d'usage déconnecté, je dois reconnaître qu'en l'espèce cela semble approprié.

      Dans mon précédent journal, j'ai lancé un appel à contribution, et même si j'ai eu des retours enthousiastes vis-à-vis du projet (qui m'ont fait très plaisir par ailleurs), je n'ai pas eu de volontaires pour le développement d'une interface web. La vie est triste.

      Précisons que ce n'est pas forcement facile de développer une interface web sur un moteur qu'on n'a pas concu et quand on ne voit pas exactement le but recherché, je me suis donc attelé à développer moi-même une interface web, de démonstration, pour montrer les possibilités du moteur, et l'idée générale. L'interface web que j'ai développée est donc une interface de démonstration, elle n'a pas vocation à rester, elle sert juste à montrer ce que fait le moteur de routage, et permet un usage minimaliste d'icelui.

      Comme d'habitude, je ne sais pas nommer mes projet, j'ai donc profité d'une similarité phonétique entre rv et le prénom hervé pour choisir le nom de mon interface, je l'ai donc nomée hervé. Vous avez le droit d'être affligés, je le suis aussi. Le nom étant trouvé, j'ai fait du développement web, cela faisait depuis 2005 que je n'avais pas fait de html et de javascript, je n'aimais pas cela, et cela n'a fait que ancrer mon opinion.

      Je n'ai pas dit que le développement web est mal, c'est juste que ce n'est pas ce que j'ai envie de faire, et comme c'est un projet que je fais sur mon temps libre, vous comprendrez très bien que je me concentre sur ce que j'ai envie de faire au détriment de ce qui m’horripile. C'est donc de l'html et du javascript pour l'interface client, avec utilisation de leaflet pour jouer avec les cartes, et c'est du python au niveau du serveur.

      L'interface de démonstration est accessible ici: Herve, limité au niveau de la France Métropolitaine. Cette interface est très moche, mais elle permet de montrer les fonctionnalités du moteur de routage. Cette instance est hébergée sur un serveur de test d'OpenStreetMap France, elle est volontairement limitée en ressource. C'est donc lent, et il y a un nombre de routage simultanés faible. De plus si vous avez la malchance d'accéder à l'interface alors que la base de données est froide, lent n'est plus le mot approprié, c'est pire. Cette interface refuse également de calculer des trajets d'une distance supérieure à 100 km à vol d'oiseau.

      Je vous invite à tester quelques trajets, et à vous amuser un peu. Pour une petite démonstration, sur la ville de Poitiers, dont le centre-ville est sur une colline, pour aller du bas de la colline au bas de la colline à l'opposé de la ville, voici deux résultats, montrant l'importance de la prise en compte de l'altitude dans le choix de l'itinéraire :

      On remarquera que Google Maps par exemple nous donne à peu près le même résultat que l'optimisation de la distance. Pour avoir vécu quelques années à Poitiers, le trajet que je préfère, et de loin, est celui résultant de l'optimisation de l'énergie.

      Documentation et code

      Tout le code du moteur, les scripts pour récupérer les données, et l'interface web est disponible sur mon répo git.

      Le répo git contient aussi la documentation (en français) sur comment se servir du tout. J'ai essayé de la faire aussi détaillée que possible, mais je doute que j'y sois complètement parvenu.

      Avenir et appel à contribution

      J'ai plusieurs rêves, et plusieurs envies.

      Interface web et API web

      J'aimerai en faire un service accessible à tout un chacun, via une interface web. Pour cela il me faudrait un ou des volontaires pour développer une vraie interface au moteur de routage, je serais bien entendu là, prêt à adapter le moteur au besoin, et à fournir toutes les explications nécessaires.

      Il est aussi envisageable de développer une API pour par exemple une utilisation via une appli de smartphone. Je n'utilise pas de smartphone, ça ne m'intéresse pas, je n'y connais rien, mais si quelqu'un est intéressé, je ne suis pas contre, même si l'interface web me paraît prioritaire.

      Il faudra aussi probablement voir du côté d'où héberger l'infrastructure. Jusqu'à maintenant l'infrastructure de test a été fournie par OpenStreetMap France, il est possible qu'ils soient volontaires pour fournir l'infrastructure.

      Moteur

      J'ai aussi plusieurs projets pour le moteur de routage

      • Abolir la règle puissance constante à vitesse élevée. C'est à dire permettre que l'utilisateur fournisse une information comme à partir de cette vitesse j'arrête de pédaler, et à partir de cette vitesse je freine. (Pour un souci de cohérence la seconde devra être supérieure à la première.)

      • Ajouter une notion d'accélération latérale maximum, ce qui implique de limiter la vitesse de passage dans un virage en fonction de son rayon de courbure. J'avais échoué par le passé à avoir quelque chose qui ne faisait pas n'importe quoi, mais j'ai réussi à tester une méthode d'approche du rayon de courbure qui donnait des résultats cohérents avec mes traces GPS (dès que je veux modifier mon modèle, j’essaie de le valider par un essai réel avec trace GPS)

      • Tenir compte du type de sol, et faire bouger le coefficient de roulement en fonction des tags OSM

      Documentation

      J'aimerais internationaliser le projet. Même si je n'ai pas de mal à écrire en anglais, j'ai rédigé la documentation en français (car j'ai plus de plaisir à écrire en français). Toutefois c'est une erreur, et je pense traduire la documentation en anglais. Bien entendu si quelqu'un veut la traduire, je profiterai du temps libéré pour faire autre chose, et j'accepterai donc avec plaisir cette contribution.

      Une fois que la documentation sera traduite, je pense supprimer la version française, déjà que c'est dur de garder la documentation à jour, si elle est présente dans les deux langues, c'est un coup à échouer.

      En bref

      • J'ai développé un moteur de routage basé sur l'énergie pour les vélocipèdistes utilisant les données d'OSM et SRTM, et j'ai encore des projets d'amélioration du moteur de routage.

      • Je propose une interface de démonstration, et je recherche des gens pour développer une vraie interface web. Au niveau licence, je demande juste une licence approuvée par l'OSI (si quelqu'un veut développer sous une licence propriétaire, je n'ai rien à redire, mais il ne recevra pas mon aide).

      • Le code et la documentation sont disponible sur un répo git. Tout est disponible sous licence BSD-2.

      • L'infrastructure jusqu'à maintenant à été fournie par OpenStreetMap France que je remercie vivement. Si vous avez envie de financièrement soutenir ce projet, c'est à OpenStreetMap France qu'il faut donner, c'est par ici.

      • Pour me contacter, vous pouvez répondre à ce journal, m'envoyer un courrier électronique (vous trouvez mon adresse dans les commits du répo git), ou encore venir me voir sur irc, je fréquente le salon #osm-fr sur oftc.

      Lire les commentaires

    • Gasoline 0.1, cadriciel applicatif pour OCaml (Journaux LinuxFR)

      Le projet Gasoline vise à implépementer un cadriciel pour le
      développement d'applications de type Unix avec OCaml. Il est
      distribué sous licence CeCILL-B.

      Les utilisateurs de Gasoline pourront:

      • Rapidement développer des applications types en utilisant des
        patrons d'application comme “filtre Unix” ou “compilateur”.

      • Écrire des application acquerrant leurs
        paramètres de configuration
        de sources variées, comme la ligne de commande, l'environnement ou
        des fichiers de configuration.

      • Écrire des applications organisées autour de
        composants logiciels
        aux responsabilités bien délimitées.

      • Amorcer et terminer facilement des applications complexes grâce à la
        gestion des dépendances pour les composants logiciels.

      • Émettre et filtrer des
        messages de diagnostic
        avec un granularité basée sur les composants logiciels.

      Liens

      Installation

      La procédure d'installation est décrite dans le fichier README du
      projet. Elle s'appuie sur BSD Make (souvent nommé bmake) et BSD
      Owl
      . Ma branche
      OPAM

      contient un package [gasoline] permettant l'installation de Gasoline.
      La procédure d'installation a été testée sous FreeBSD 10.0, Debian
      Jessie et Mac OS X.

      Qu'est-ce qu'un patron d'application

      Pour prendre un exemple simple et bien connu, l'écriture d'un filtre
      Unix devrait essentiellement se résumer à la préparation d'une
      fonction filter

      val filter : parameter -> in_channel -> out_channel -> unit

      implémentant le traitement réalisé par le filtre — parameter est le
      type fictif des paramètres contrôlant le filtre.

      Un patron d'application devrait prendre en charge les tâches
      d'intendance, comme l'initialisation des composants logiciels et
      l'acqusition des paramètres de configuration.

      Plusieurs patrons d'application sont prévus pour la version
      0.3.

      Exemples de programmes utilisant Gasoline

      Le dossier
      example
      contient trois exemples de programmes.

      Le programme
      punishment
      écrit 100 fois sur sa sortie standard la phrase

      I must not talk in class
      

      Il illustre la définition de paramètres de configuration et
      l'acquisition des paramètres de configuration depuis des sources
      variées.

      Le programme
      wordcount
      est une version à l'organisation sur-développée du classique programme
      wc(1). Il illustre l'utilisation de composants logiciels dans un
      exemple minimal et très petit.

      Le programme
      wordgen
      analyse une liste de mots et génère des mots supplémentaires ayant les
      mêmes caractéristiques. Le dossier de l'exemple contient une liste
      tolkien.text rassemblant une liste de noms provenant des œuvres de
      Tolkien. Pour générer des mots semblables, on analyse cette liste avec

      ./wordgen -d . -C tolkien.text

      puis on demande la génération de, disons, 16 mots, avec

      ./wordgen -d . -G tolkien.text -n 16
      galdal
      arathlor
      mirmilothor
      eoron
      echalad
      aerecthilmin
      foros
      erion
      cuarveranwen
      tiladhruil
      brint
      luindor
      marin
      sulkoron
      halia
      nengirhuri

      L'option -d spécifie le dossier qui doit être utilisé comme
      bibliothèque de listes de mots.

      Conclusion

      Vos commentaires, remarques, idées et bien-sûr vos contributions, sont
      les bienvenus!

      Lire les commentaires

    17:25 'tain, on se croirait à la maternelle quand les gamins découvrent
    les crayons de couleurs...
    17:26 <B> <I> <S> <U> <EM> <TT> <STRONG> toutes les balises en même temps
    </B> </I> </S> </U> </EM> </TT> </STRONG>
    17:31 17:25 ou mieux, les feutres ! mais certains ici oublient d'enlever
    les bouchons .... (17:26)