Lorsqu’une personnalité notoire du Libre comme Carl Chenet s’attaque avec pertinence à la tendance massive du « tous sur GitHub » et égratigne la communauté du Libre pour son immobilisme (et même sa paresse !), Framasoft trouve que c’est une bonne occasion de lui donner un peu plus de voix encore.

S’adressant principalement aux développeurs, il pointe les dangers d’un d’un service centralisateur, privateur, qui uniformise les pratiques en étouffant les alternatives. Ça ne vous rappelle rien ? Oui, les mêmes écueils contre lesquels nous vous mettons en garde dans notre campagne degooglisons ! Ajoutons que nous avons déjà basculé sur GitLab, comme le recommande Carl, dès 2014 et mis à la disposition de tous depuis le mois de mars 2015 notre GitLab qui héberge à ce jour 3017 projets, 2071 utilisateurs inscrits, 242 groupes.

Nous reprenons ici avec son autorisation le récent billet de Carl qui a déjà suscité d’intéressants commentaires et en provoquera probablement d’autres ici même.

Le danger GitHub

Un article de Carl Chenet d’abord publié sur son blog

Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez GitHub (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de GitHub par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.

L’octocat, mascotte de GitHub

Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par GitHub ont pris une place considérable dans l’ingénierie logicielle ces dernières années.

Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.

1. Points critiques

1.1 La centralisation

L’application GitHub appartient et est gérée par une entité unique, à savoir GitHub, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.

De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas GitHub, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on n’est pas « dans le coup » quand on n’utilise pas GitHub, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).

1.2 Un logiciel privateur

Lorsque vous interagissez avec GitHub, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de GitHub on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec GitHub). Et surtout un outil crucial propriétaire fourni par GitHub qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.

1.3 L’uniformisation

Travailler via l’interface GitHub est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant GitHub comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils GitHub en travaillant pour une autre société. Cette fréquence de l’utilisation de GitHub dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.

L’uniforme évoque l’armée, ici l’armée des clones

2. Validité des points critiques

2.1 Les critiques de la centralisation

Comme dit précédemment, GitHub est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée.  Des attaques massives par déni de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5 % des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de GitHub elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.

L’excuse n°1 des programmeurs pour se lâcher sans scrupules : « GitHub est en panne »

— Hé, au boulot les gars ! — Github est en panne !

— Ah bon, continuez alors.

2.2 Les critiques relatives à l’usage d’un logiciel privateur

Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek,  car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.

Les tenants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser GitHub. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.

FreeBSD, principal projet des BSD sous licence MIT

Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de GitHub elle-même, l’utilisation du gestionnaire de suivi de bugs de GitHub pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.

GitHub propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de GitHub  ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par GitHub ?

L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo ! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez GitHub serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800 000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez GitHub ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de GitHub.

Debian, l’un des principaux projets du Logiciel Libre

avec autour de 1000 contributeurs officiels

2.3 L’uniformisation

La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.

GitHub a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.

Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur GitHub avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.

Et c’est bien dommage car GitHub, en proposant une expérience unique et originale à ses utilisateurs, taille à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à GitHub d’initier à Git les nouveaux arrivants dans le développement  à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.

Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?

Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.

L’effet GitHub est donc délétère au point de vue des effets qu’il entraîne : la centralisation,  l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre « Cher GitHub… » met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de GitHub d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.

Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternatives et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capables de programmer devraient avoir ce réflexe. Vous n’aimez pas ce qu’offre GitHub ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.

Logo de Gitlab, une alternative possible à GitHub

en choisissant la version Communauté

Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à GitHub et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.

Finalement, l’utilisation de GitHub suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec GitHub. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.

Le « lion » du Libre assoupi devant la cheminée (allégorie)

Liens :

• Source de l’article : blog de Carl Chenet
• Notre GitLab ouvert à tous (pour sortir de Github)

Original post of Framablog.Votez pour ce billet sur Planet Libre.

La Piscine de C++ qui marque le début de notre deuxième année à Epitech vient de se terminer. Durant ces deux semaines on étudie à fond la quasi-totalité des concepts liés à la POO.

Rapidement tout le monde a commencé à chercher tout ce qui pouvait nous faciliter la vie pour coder, et de nombreux étudiants se sont tournés vers des IDE très puissants, mais aussi très lourds. Moi je suis du genre à rester sur mon Neovim même si j’ai moins de fonctionalités, au moins ça marche et je sais ce que je code.

Mais mon égo en a pris un coup au vu de toutes les fonctionnalités de ces IDE et j’ai eu envie de développer un plugin qui puisse faire, à défaut de complètement, certaines choses de façon équivalentes à ces IDE. Pour ça j’ai dû apprendre à utiliser l’API Python de Neovim, et la librairie de parsing CLang.

Mon plugin en est à ses balbutiements mais je compte bien l’améliorer au fil du temps. Je vais commencer par parler un peu de la création d’un plugin dans Neovim, puis du fonctionnement de CLang. Dans un prochain article je rentrerais un peu plus dans les détails sur la façon dont j’ai fait fonctionner les deux ensembles, mais cet article est déjà bien assez long ;)

Neovim

Neovim a totalement changé son API pour les plugin par rapport à Vim, en utilisant msgpack pour pouvoir créer des clients comme on veut dans le langage qu’on veut pour faire une API, un GUI, etc…

Dans mon cas je connais le Python, il y a une API Python, du coup je l’ai codé en Python, tout le monde suit? ;) Mais il y a de nombreux autres clients, vous pouvez voir la liste ICI.

Pour m’aider j’y suis allé pas-à-pas en suivant plusieurs exemples donnés sur le dépôt de l’API Python.

Bon assez parlé place à l’action, comment ça fonctionne un plugin Neovim avec Python? Déjà il faut installer cette API, cela se fait par le biais de la commande suivante:

sudo pip install neovim

J’ai appelé mon plugin easy-cpp.nvim, je met dans un dossier éponyme le contenu de mon plugin, qui se résume par:

• Un README.md qui fera office d’introduction notamment sur Github
• Un fichier LICENSE (MIT dans mon cas, j’aime bien cette license :3)
• Un dossier rplugin/python

rplugin est pour Remote Plugin, c’est-à-dire les plugins qui son gérés grâce a une API client telle que celle de Python. et le dossier python permet d’indiquer pour quel langage ce plugin est destiné.

Ce dossier est lui-même composé du:

• dossier easy-cpp/ qui va contenir tout le code, qui pour le moment n’est que dans un fichier init.py parce que je suis sale
• fichier easy-cpp.py, qui est vide et qui le restera.

Allons ensuite maintenant dans ce fichier init.py. Il contient principalement une classe avec un décorateur de neovim pour indiquer que cette classe dirige le plugin. Cette classe est initialisée avec un paramètre qui est le client de vim en lui-même. Cet objet va servir à faire toute l’interaction avec notre éditeur de texte préferé.

@neovim.plugin
class Easy(object):
  def __init__(self, vim):
    self.vim = vim
    ...

  @neovim.command('EasyGenerate')
  def generate(self):
    ...

On voit ici que j’ai utilisé deux décorateurs liés à neovim. @neovim.plugin permet donc de marquer votre classe comme étant celle qui gère le plugin comme je l’ai déjà dit. @neovim.command est à placer sur une méthode de votre classe.

Elle va permettre de transformer votre méthode en commande pour Neovim. C’est-à-dire qu’une fois Neovim lancé, on peut taper :EasyGenerate et la fonction generate() va être lancée. Dans le principe c’est le gros de ce qu’il y a a apprendre pour créer un plugin pour Neovim. Mais il y a encore une chose dont je doit parler et qui est essentiel pour insérer du texte dans un fichier: la variable Buffer.

On a notre objet self.vim qui contient énormément d’informations sur l’état actuel de l’éditeur (je vous invite a voir les fichiers de tests unitaires de l’API Python qui contiennent pas mal d’information sur le sujet). Parmis les variables qu’il contient j’ai principalement eu à utiliser self.vim.current.buffer et self.vim.buffers

self.vim.buffers est un tableau qui contient chacune des lignes qui existent dans chacun des buffers ouverts. Le premier niveau du tableau (buffers[0], buffers[1], etc…) contient tour à tour les buffers ouverts. Le deuxième niveau (buffers[0][2], buffers[4][1:5], etc…). Pour modifier il suffit d’assigner une chaine de caractère à une ligne d’un buffer, ou meme un tableau de chaines de caractères.

Pour ajouter à la fin d’un buffer il y a deux possibilités: soit on veut ajouter à la fin et dans ce cas on fait buffers.append(maChaineOuMonTableau), soit on veut intercaler une ou des lignes entre deux autres, par exemple si je veux insérer du texte à la ligne 42 je fais buffers.append(maChainOuMonTableau, 42). Au final c’est comme un tableau classique en Python :)

CLang

CLang est extrêmement puissant, mais il n’y a malheureusement que peu de ressources documentaires sur le sujet, et encore moins pour la librairie en Python. Ayant réussi à faire deux trois chose avec je me suis dit que partager avec tout le monde ce que j’ai appris pourrait en pousser d’autres à faire le pas ;) (et m’apprendre des choses en retour!)

J’ai commencé par suivre ce tutoriel tout d’abord aux conseil de mon ami Strackeror: http://szelei.me/code-generator/.

Ce tutoriel est très bien écrit (mais en anglais bien sûr), et il vous donne les bases pour comprendre CLang et l’utiliser dans Python. Mais dans mon cas je ne l’ai pas suivi en entier car mon but était un peu différent de ce qu’il voulait faire. Mon but est d’utiliser CLang pour analyser un fichier d’en-tête C++, et en extirper les prototypes de chaque méthode avec leur espace de nom.

Je m’explique, j’ai fait un fichier de header pour mes tests, et un fichier de source pour comparer le résultat final que je veux:

#ifndef TEXTCOMPONENT_H
# define TEXTCOMPONENT_H

#include 

namespace Test
{
  namespace inerTest
  {
    class TextComponent
    {
      public:
          TextComponent();

          std::string text() const;
          void setText(const std::string& value);

      private:
          void superSecretFunction();
          std::string m_text;
    };
  }

  class newText
  {
    public:
      newText();
      newText(newText const&);
      newText& operator=(newText const&);
  };
}

class OutText
{
  public:
    OutText();
    OutText(OutText const&);
    OutText& operator=(OutText const&);
};

void outputsmthing(int, int);

#endif /* TEXTCOMPONENT_H */

Et ce que je veux obtenir:

#include "textcomponent.h"

std::string Test::inerTest::TextComponent::text() const
{

}

void Test::inerTest::TextComponent::setText(const std::string & value)
{

}

void Test::inerTest::TextComponent::superSecretFunction()
{

}

Test::newText & Test::newText::operator=(const Test::newText &)
{

}

void outputsmthing(int, int)
{

}

OutText & OutText::operator=(const OutText &)
{

}

J’ai volontairement fait un cas pas très joli d’encapsulation dans des espaces de noms, mais bon au moins si là ça fonctionne c’est que je suis sur une bonne base!

Donc pour générer ça, on va avoir besoin d’installer clang pour python, pour ça rien de tel qu’un:

sudo pip install clang

Ensuite on ouvre un fichier python à coté de notre fichier header (je ne parle pas du fichier init.py de tout à l’heure là on se met dans un autre dossier pour travailler sur autre chose sans le lier au plugin). On commence ce fichier en initialisant clang, lui demandant de créer un index, et de parser un fichier donné en paramètre avec sys.argv[]. Enfin, on va utiliser la sortie pour génerer la liste des fonctions du fichier de header:

from clang import *
import sys

cindex.Config.set_library_file('/usr/lib/llvm-3.4/lib/libclang.so.1')
index = cindex.Index.create()
translation_unit = index.parse(sys.argv[1], ['-x', 'c++', '-std=c++11', '-D__CODE_GENERATOR__'])

def get_methods(cursor):
    name = cursor.spelling
    functions = []

    for c in cursor.get_children():
        if (c.kind == cindex.CursorKind.CXX_METHOD):
            functions.append(c)
    return functions

def get_all_public_functions(cursor):
    result = {}
    for c in cursor.get_children():
        if (c.kind == cindex.CursorKind.CLASS_DECL) and c.location.file.name == sys.argv[1]:
            a_class = get_methods(c)
            result[c.spelling] = a_class
        elif (c.kind == cindex.CursorKind.NAMESPACE) and c.location.file.name == sys.argv[1]:
            child_classes = get_all_public_functions(c)
            result[c.spelling] = child_classes
        elif (c.kind == cindex.CursorKind.FUNCTION_DECL) and c.location.file.name == sys.argv[1]:
            result[c.spelling] = c
    return result

classes = get_all_public_functions(translation_unit.cursor)

Pas de panique je vais tout expliquer!

Les premières lignes sont expliquées dans l’article que j’ai mis en lien plus haut, je ne pense pas avoir besoin de revenir dessus.

Tout en bas on assigne à classes le retour de la fonction get_all_public_functions qui prend en paramètre un objet Cursor. Cet objet propre a CLang contient tout un tas d’informations sur chaque segment de code, sous forme d’arbre.

Dans get_all_public_functions() on parcourt la liste des enfants de ce Cursor avec la méthode get_children(), la variable c obtenue est un…Cursor, vu que nous sommes dans un arbre de Cursors, chaque enfant est un autre Cursor dépendant de son parent.

Cet objet contient de nombreuses informations, dont c.kind qui indique le type du Cursor. Dans notre cas on vérifie pour trois valeurs:

• Si c’est un classe (CLASS_DECL), dans ce cas-là on appelle la fonction get_methods() plus haut qui récupère toutes les méthodes de cette classe.
• Si c’est un namespace (NAMESPACE) on recupère de façon récursive le retour de get_all_public_functions() avec comme valeur l’enfant courant. Puis on l’ajoute à result.
• Si c’est une fonction (FUNCTION_DECL), on l’ajoute simplement à result.

result étant un dictionnaire, on lui passe en guise le clé c.spelling, qui correspond au code en lui-même pointé par le curseur, dans notre cas c’est soit un nom de classe, soit un nom de namespace, soit un nom de fonction.

Petit détail, la condition c.location.file.name == sys.argv[1] permet de vérifier qu’on parle toujours du même fichier, et pas d’un fichier récuperé lors d’un #include, qui sera aussi parsé par CLang quoiqu’on fasse, sauf qu’on veut pas l’ajouter en résultat ;)

La suite au prochain épisode…

Original post of Ilphrin.Votez pour ce billet sur Planet Libre.

Effectivement, malgré les fêtes de fin d'année, malgré l'après-fêtes de fin d'année et malgré la crève qui court, voici le numéro 104 en français. Il s'agit du dernier numéro de l'an 2015 ; pour le visionner ou le télécharger, c'est ICI, ou, pour un téléchargement simple, vous pouvez cliquer sur la couverture ci-dessous.

Bien que ne faisant que 53 pages, vous y trouverez plein de bons articles, dont :

• Comme indiqué sur la couverture, le début d'une série sur comment fabriquer votre propre imprimante 3D ;
• comment installer Mint, ou apparemment tout *buntu, sur RAID 0 ;
• des tutoriels habituels, Python dans le monde réel, LivreOffice et Inkscape ;
• une présentation de l'utilisation de TOP ;
• la critique de Steam Link et le contrôleur, dans Jeux Ubuntu;
• et non pas une, mais deux, critiques littéraires !

Nous vous en souhaitons bonne lecture,

Toute l'équipe du FCMfr, et, pour ce numéro :

• Le scribeur : Bab
• Les traducteurs : AE, d52fr, erlevo, fredphil91, lejimi
• Les relecteurs : Bab, d52fr, erlevo, et moi-même, AuntieE

Original post of Full Circle Magazine FR.Votez pour ce billet sur Planet Libre.

Un exemple frappant d’une technique d’enfermement des utilisateurs à une plateforme et de création d’externalité est le non support de CalDAV.

Pour info, ces 2 formats sont standardisés par l’IETF (2007 pour CalDAV, 2011 pour CardDAV) et permettent d’échanger et synchroniser un calendrier et un carnet de contacts respectivement.

Visiblement, ce n’intéresse que les utilisateurs et pas Microsoft. Son cloud Office365 ne propose pas de connexion CalDAV malgré de nombreuses requêtes utilisateurs depuis 2013.

Microsoft oblige a utiliser un client Microsoft Exchange et il n’existe pas à ma connaissance de client calendrier à Microsoft Exchange open source pour Android.

Si vous voulez rire, voici ce que propose Android (stock) lorsque vous souhaitez ajouter un compte Exchange :Plus concrètement, vous donnez à l’administrateur de votre compte Microsoft Exchange les droits suivants :

• Effacer toutes vos données
• Définir des règles pour les mots de passe
• Surveiller les tentatives de déverrouillage de l’appareil
• Bloquer l’écran de déverrouillage de l’appareil
• Choisir la date d’expiration du mot de passe
• Activer/désactiver le chiffrement de l’appareil
• Désactiver les caméras

Et si vous n’acceptez pas ces conditions, vous ne pouvez pas vous connecter à vos données… Si c’est Google qui a fait ça, chapeau. Ça rebute suffisamment.

Quand à l’application officielle Microsoft Outlook, il faut lui donner bien entendu accès à vos contacts, calendriers, comptes, fichiers, etc… même ceux qui ne sont pas lié à votre compte Office365 sans sourciller de ce qu’en fera l’application dans votre dos. Problème inhérent à toute application au code source fermée qui manipule des données personnelles.

La solution, créer un second utilisateur sur l’appareil Android, et y installer l’application Outlook. Ainsi l’application n’aura accès qu’aux données de ce compte.

Related Posts:

• Récupérer les mots de passe Wifi sur Android
• Changer son adresse MAC de manière permanente sous Android
• Tracking par les émissions Wifi et Bluetooth
• Samsung Galaxy S3 : de Android 4.0 à 5.1
• Android 6 M donne l’accès Internet aux applications sans vous le dire… et vous ne pouvez pas le désactiver

J'aime(0)Ferme-la !(0)

Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.

FontAwesome permet d'ajouter une police d'icônes simplement sur votre site web (585 icônes). Au contraire des images, les icônes s'adapteront à la taille du texte sans pixéliser. FontAwesome intègre également des règles CSS pour faciliter la mise en page et l'utilisation de la police.

Les icônes peuvent être utilisées dans le thème du site mais s'insèrent facilement dans le contenu d'un article.

FontAwesome peut être utilisé facilement sur n'importe quel site, du simple site fait à la main en HTML au CMS. Avec PluXml, il est existe une solution facile avec PlxMyFontAwesome, dans ce cas il suffira simplement d'activer le plugin pour en profiter.

Installer FontAwesome

Pour les utilisateurs de PluXml, je recommande l'utilisation de PlxMyFontAwesome. Il existe aussi une méthode plus générique valable pour n'importe quel site.

Pour information, il est possible de passer par un site tiers permettant d'utiliser automatiquement la dernière version disponible. Je ne recommanderai pas cette méthode mais elle est documentée sur le site du projet.

PlxMyFontAwesome: plugin pour PluXml

PlxMyFontAwesome permet d'installer et d'utiliser très simplement FontAwesome avec PluXml. La police est contenue dans le plugin et évitera de faire appel à un site tiers pour afficher les icônes (tracking des utilisateurs). Il inclut également la documentation nécessaire (code, css class et unicode) pour l'utiliser en toute autonomie.

Pour installer le plugin, il faut commencer par récupérer l'archive sur mon dépôt de plugins Pluxml. Il est également disponible sur Github mais il faut penser à renommer le dossier contenu dans l'archive en "plxFontAwesome".

Une fois l'archive décompressée, il faut envoyer le dossier "plxFontAwesome" via FTP sur votre site et le déposer dans "/plugins".

Après avoir copié le plugin dans votre PluXml, il ne vous reste plus qu’à l’activer. Pour ça, il faut se connecter sur le site en tant qu'administrateur et aller dans le menu: Paramètres > Plugins.

Dans l'onglet Plugins inactifs, sélectionner le plugin plxFontAwesome et dans le menu déroulant "Pour la sélection" choisir "Activer", puis cliquer sur le bouton "Ok" pour enregistrer la modification.

Une fois activé, vous devriez avoir accès dans le menu à un onglet nommé FontAwesome avec le récapitulatif de toutes les icônes disponibles.

L'avantage du plugin est d'activer FontAwesome sur tous les thèmes disponibles de votre site. Il est possible d'activer et désactiver la police facilement (ou la supprimer si elle n'est plus utile) depuis l'interface d'administration de PluXml.

On peut maintenant passer directement à la partie Utiliser FontAwesome.

Installer FontAwesome pour n'importe quel site

Cette solution devrait fonctionner pour n'importe quel site.

1. Récupérer l'archive sur le site officiel.
2. Copier le dossier FontAwesome sur votre site.
3. Ajouter la feuille de style font-awesome.min.css dans la balise de votre site.

code à ajouter:

...
<link rel="stylesheet" href="path/to/font-awesome/css/font-awesome.min.css">
 

Utiliser FontAwesome

Une fois que FontAwesome est bien installé sur le site, on va pouvoir l'utiliser.

Pour les exemples on prendra l'icône fa-rocket. On retrouve toutes les informations de cette icône sur cette page. Pour ceux qui utilisent le plugin PlxMyFontAwesome, la liste des icônes est disponible dans le menu, sinon elle est disponible ici.

Ajouter des icones dans votre page/article

La solution la plus simple consiste à récupérer et copier le code de l'icône dans votre page.

Pour ajouter , il faudra ajouter dans le code HTML de la page:

On ne pas faire plus simple .

Ajouter des icônes dans le css/thème

On peut également intégrer des icônes dans le thème de votre site via le fichier CSS.

Fil RSS des articles
Pour rajouter une icône devant la classe .rss, il suffit d'ajouter:

Fil RSS des articles

.rss:before {
    font-family: FontAwesome;
    content: "\\f135";
} 

Mettre en forme les icônes

Je ne vais pas détailler toutes les fonctionnalités de FontAwesome, mais il existe différentes astuces pour mettre en forme correctement ses icônes.

Agrandir la taille de l'icone

Il est possible de définir rapidement la taille des icônes.

 fa-lg
 fa-2x
 fa-3x
 fa-4x
 fa-5x 

Empiler les icônes

Il est possible de créer des icônes un peu plus évoluées.

Ajouter un fond rond derrière une image:

  
  

fa-flag on fa-circle
 

Faire un calendrier:
27

  
  27
 

.calendar-text { margin-top: .3em; } 

Les autres astuces sont disponibles sur http://fontawesome.io/examples/ et aussi sur http://blog.fontawesome.io/.

Convertir facilement des icônes en .png

Si vous avez besoin d'ajouter des images dans un support qui sont disponibles dans FontAwesome ou d'autres polices d'icônes, je vous conseille d'aller sur http://fa2png.io/. On peut générer très facilement une image à partir d'une icône et définir la couleur, la couleur de fond et la taille.

Ressources

• http://fontawesome.io/
• http://fontawesome.io/examples/
• http://blog.fontawesome.io/
• http://fontawesome.io/cheatsheet/
• https://fortawesome.github.io/Font-Awesome/cheatsheet/
• http://fa2png.io/

Original post of nIQnutn.Votez pour ce billet sur Planet Libre.