PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Raphaël Hertzog : Le logiciel libre a t’il une couleur politique ?

vendredi 21 avril 2017 à 14:36

En pleine campagne présidentielle, après avoir échoué à obtenir les parrainages pour Charlotte Marchandise, j’ai décidé de soutenir Jean-Luc Mélenchon.

Il se trouve que le volet numérique du programme de la France Insoumise est très bien ficelé et fait la part belle aux logiciels libres.

Mais face aux enjeux, ce n’est évidemment pas mon seul critère de choix. L’élément décisif pour ma part est la mise en place d’une assemblée constituante avec des citoyens tirés au sort pour changer nos institutions et notre système électoral à bout de souffle. Il nous faut le jugement majoritaire (cliquez le lien pour tester la méthode sur cette élection présidentielle) pour en finir avec le vote utile. Il faut dépasser la monarchie présidentielle et apprendre à travailler ensemble pour le bien de tous.

Mais même en allant au delà de ces deux aspects, je me retrouve en accord avec le programme de la France Insoumise sur la quasi totalité des thématiques sauf l’Europe et sur le revenu universel (qui est absent!).

Pour autant, je n’aime pas le personnage de Jean-Luc Mélenchon (ce n’est pas pour rien que je soutenais Charlotte Marchandise) et son historique politique (cumul dans le temps…) n’est pas en phase avec mes convictions, mais il n’y a pas de candidat parfait et il a promis de démissionner une fois la nouvelle constitution en place alors je m’en accommode.

Bref, pour en revenir avec le sujet de mon article, très peu de candidats[1] à la présidence ont pris des positions aussi claires en faveur des logiciels libres alors je m’interroge. Est-ce un hasard que le seul projet qui défend le logiciel libre soit aussi celui qui me correspond le mieux par ailleurs ? Ou bien est-ce que le fait que je fasse partie de la communauté du logiciel libre peut avoir une relation avec le côté humaniste/progressiste/écologiste qui m’attire en politique ?

J’ai l’habitude de présenter le logiciel libre comme apolitique, car les gens de gauche y voient un modèle de coopération et de partage des communs, et les gens de droite y voient la liberté totale et un marché ouvert avec une concurrence parfaite. Et parfois j’ai l’impression que cette distinction se retrouve aussi dans la différence de terminologie « logiciel libre » vs « open-source »…

L’existence même de ces deux tendances discréditerait alors la corrélation que je semble observer. Mais tout de même, lorsqu’on parle de « communauté du logiciel libre » j’ai remarqué que ceux qui se reconnaissent derrière ce label sont plutôt des contributeurs qui sont portés par des motivations (au moins partiellement) altruistes et lorsque je discute avec d’autres contributeurs bénévoles aussi impliqués que moi, il est assez rare que je tombe sur des personnes avec des valeurs en forte opposition aux miennes.

Ceux pour qui le logiciel libre se résume à l’open-source ne semblent pas s’identifier à la notion de communauté du logiciel libre et sont moins impliqués/présents/visibles dans les événements qui fédèrent les communautés (conférences, sprints, etc.).

Qu’en dites-vous ? Faites-vous le même constat que moi ? Ou bien avez-vous une expérience diamétralement opposée à la mienne ?

Il est possible (voire probable) que la communauté Debian (dont je fais partie) ne soit pas forcément représentative de l’ensemble de la communauté du libre. L’existence même du contrat social comme texte fondateur explique peut-être un biais vers le côté humaniste/progressiste.

En tout cas, avec le nombre de chercheurs qui ont déjà étudié les développeurs de logiciels libres, je m’étonne que cette problématique n’ait pas encore été étudiée. Si vous connaissez une étude à ce sujet, partagez la dans les commentaires, cela m’intéresse et je rajouterai volontiers un lien dans l’article.

[1] François Asselineau soutient aussi le logiciel libre. Mais j’ai l’impression que c’est plus par anti-impérialisme américain — car les logiciels propriétaires dominants viennent de là — que par conviction.

Un commentaire | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

Gravatar de Raphaël Hertzog
Original post of Raphaël Hertzog.Votez pour ce billet sur Planet Libre.

Articles similaires

Tuxicoman : Debian : connecter une sortie audio bluetooth

vendredi 21 avril 2017 à 07:49

Il y a un bug très gênant lorsque l’on veut connecter un périphérique Bluetooth audio (A2DP) sur Debian, celui-ci n’apparaît pas comme sortie audio dans Pulseaudio.
Pourquoi? Parce que GDM le capture avant pour son propre usage.

Pour désactiver ce comportement, créer le fichier /var/lib/gdm3/.config/pulse/client.conf et indiquer dedans ceci :

autospawn = no
daemon-binary = /bin/true

Ensuite donnez le droits de l’utilisateur Debian-gdm au fichier:

# chown Debian-gdm:Debian-gdm /var/lib/gdm3/.config/pulse/client.conf

Puis redémarrez.

Ainsi lorsque vous connecterez le périphérique bluetooth, cecui-ci sera alors bien visible dans les sorties son de pulseaudio.

Related Posts:

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

Marthym : GitLab-CI + Docker Hub

vendredi 21 avril 2017 à 02:00

Il y a pas loin d’un an, j’ai décrit sur l’une des nombreuses manière d’automatiser une release grace à Github et Travis CI.

Depuis, les nouvelles versions de Gitlag intègre des fonctionnalités d’intégration continue. Couplé avec des services comme Framagit qui permettent d’avoir des repos git privé, ça permet d’avoir gratuitement accès à une infrastructure d’intégration continue gratuite pour toutes sortes de projets personnels.

Je prends pour exemple une projet perso en latex SW-Redemption pour vous montrer ce qu’il est possible de faire avec gitlab-ci.

Configuration de gitlab-ci

Un peu comme pour travis qui lit un fichier .travis.yml, gitlab-ci utilise un fichier .gitlab-ci.yml (super original). Mais contrairement à celui de travis, il est vraiment plus simple, en tout cas à fonctionnalités égales. Toute la config est détaillée ici (en anglais).

Voilà ce que j’ai dans mon fichier

before_script:
  - apt-get update -qq && apt-get install -y -qq texlive-base texlive-xetex texlive-latex-recommended texlive-latex-extra texlive-extra-utils texlive-fonts-recommended texlive-font-utils texlive-lang-french texlive-math-extra texlive-pictures latex-xcolor texlive-bibtex-extra pgf lmodern biber latexmk ghostscript

swr-SNAPSHOT:
  stage: build
  script:
    - latexmk -f -r swr-class/latexmkrc || true
    - mv "build/swr-livre-joueur.pdf" "build/SW-Redemption, Livre du joueur.pdf"

  artifacts:
    expire_in: 1 day
    paths:
    - "build/SW-Redemption, Livre du joueur.pdf"
  allow_failure: true

Déjà à ce niveau, on voit que l’on crée l’artefact et que l’on a pas à se compliquer la vie avec les clé de connexion au repo. Rien que ça c’est appréciable. Après certes les fonctionnalités de release de Gitlab sont pas les mêmes que celles de Github mais ça fait bien le job.

Bref, la killer feature c’est ça :

image: marthym/latex:1.0.0

swr-SNAPSHOT:
  stage: build
  script:
    - latexmk -f -r swr-class/latexmkrc || true
    - mv "build/swr-livre-joueur.pdf" "build/SW-Redemption, Livre du joueur.pdf"

  artifacts:
    expire_in: 1 day
    paths:
    - "build/SW-Redemption, Livre du joueur.pdf"
  allow_failure: true

Il est possible d’utiliser des images Docker, présentent sur DockerHub. Et ça permet de ne plus avoir à faire les installations pre-build, particulièrement longue pour LaTeX. En plus ça permet aussi de tester le build depuis votre machine dans le container Docker. Pas besoin de committer dix fois pour trouver ce qui ne s’est pas bien installé sur l’image de Travis. Grace à cette fonctionnalité, on connaît exactement la version du système qui lance le build et si l’on utilise des packages en version récente, pas de soucis.

En bref c’est top.

Vous pouvez comparez le gitlab-ci et le travis-ci du projet en question.

Création de l’image Docker

Je fais un paragraphe rapide, c’est pas le but du post.

En gros, il faut se créer son Dockerfile et le pousser sur Github, vous trouverez le mien . Ensuite vous créez un compte sur DockerHub. Puis vous allez dans “Create” » “Create Automated build” et vous choisissez Github. Le reste est assez clair et simple.

Ensuite chaque fois que vous poussez sur Github, ça builde le docker. Une fois builder, il est disponible pour Gitlab-ci.

GitLab-CI + Docker Hub écrit à l'origine par Marthym pour J'ai acheté un PC neuf cassé ... le April 21, 2017.

Gravatar de Marthym
Original post of Marthym.Votez pour ce billet sur Planet Libre.

Jean-Baptiste Holcroft : La plateforme de traduction Pontoon

vendredi 21 avril 2017 à 00:00

Dans un précédent article, j’ai décrit ce qu’était pour moi une bonne plateforme de traduction, voici mon retour d’expérience sur Pontoon. C’est déjà un bon outil alors qu’il est encore en pleine maturation, bien adapté pour les projets bien organisés, moins pour les plateformes génériques/multi-projets (ex: Fedora l10n ou Suse l10n).

La technique

Ça commence bien, même si Pontoon est géré par mozilla (qui pousse le L20N), cet outil prend en charge divers formats bien connus : gettext, XLIFF, L20n, lang, properties, etc.

On voit ici que les développeurs ont compris comment faciliter la vie tant des développeurs que des traducteurs, puisque la synchronisation avec un dépôt est obligatoire, encore une fois les standards sont respectés : SVN, HG et Git. On limite ainsi les risques de désynchonisation, et via un mécanisme de robots, l’outillage est complet pour faire de l’automatisation.

On notera que sur la majorité de ses projets, Mozilla crée des dépôts dédiés pour les traductions, allant jusqu’à faire un dépôt par langue (pour une question de gestion des droits).

Le support au travail d’équipe

La plateforme utilise une structure générale simple et efficace : langue > projet > ressource > interface de traduction. On retrouve cette structure à l’identique dans l’adresse de navigation.

L’entête de la page affiche systématiquement les informations utiles. C’est tellement simple que je n’ai même pas besoin d’une impression d’écran pour l’expliquer :

French fr
    Plural forms* one, other
    Script Latin
    Writing direction Left-to-right
    Number of literate speakers* 231,632,000
    Translated strings 53,584
    Suggested strings 16
    Fuzzy strings 0
    Missing strings 64
    All strings 53,664

L’équipe française fonctionne par un mécanisme de validation. Seules quelques personnes peuvent valider le contenu tandis que toutes peuvent suggérer des améliorations. Encore du pragmatisme, bravo à ceux qui ont mis en place ce mécanisme simple et efficace, c’est un peu fermé car tout le monde n’est pas à égalité, mais extrêmement simple à comprendre.

Quand on descend dans un projet, on voit plein d’autres choses utiles, allant du point de contact à l’échéance de traduction, incluant le degré de priorité, les sites de production et de développement et le dépôt… Que demander de plus ?

EU Copyright campaign French :
    Priority
    Deadline Mar 10, 2017
    Repository github.com/mozilla/copyright
    Resources Production site · Development site
    Contact person Théo Chevalier

Si on est capable de voir les contributeurs les plus actifs (et les contacter), il n’est malheureusement pas possible de discuter dans l’outil, que ce soit sur une phrase, sur un projet ou avec le mainteneur. Les échanges doivent donc se reporter sur une liste de discussion, un canal IRC ou autre. Pontoon étant en développement, il est probable que cela vienne un jour.

L’aide à la traduction

L’interface d’édition est simple et efficace, focalisée sur le travail de traduction et ergonomique. On y retrouve les suggestions, la traduction automatique (via mémoire de traduction ou outils en ligne) et les traductions menées par d’autres équipes de traduction.

Les points évoqués dans le travail d’équipe confirme qu’il y a donc nombre d’étapes très limité pour trouver son projet et commencer à travailler, ainsi que pour comprendre le parcours de la traduction à la diffusion/publication de notre travail.

La mémoire de traduction n’est cependant pas interrogeable directement depuis Pontoon, il faut aller sur un autre outil maison de Mozilla.

Bilan

C’est donc globalement une plateforme très intéressante, à laquelle il ne manque pas grand-chose pour pouvoir être utilisé par n’importe quelle structure :

À ce stade, elle ne pourrait pas vraiment être utilisée par Fedora par exemple, mais on y est presque !

Gravatar de Jean-Baptiste Holcroft
Original post of Jean-Baptiste Holcroft.Votez pour ce billet sur Planet Libre.

Articles similaires

blog-libre : Des news de Ansible

jeudi 20 avril 2017 à 16:00

A ma grande stupeur il n’y a eu quasiment aucune info sur la sortie de la version 2.3 de Ansible le 12/04. En Français rien de rien et en Anglais un malheureux article dans ZDNet vide d’intérêt. Il se trouve que j’attendais avec impatience cette version, profitons-en pour faire le point.

Les grosses news

Ansible s’est fait racheter par Red Hat en octobre 2015. On aurait pu craindre que l’outil soit relégué au second plan mais 18 mois plus tard on constate que le rythme de développement est toujours soutenu et que l’outil continue de s’améliorer. Dans l’absolu le rachat est une excellente nouvelle car ça pérennise Ansible et augmente sa popularité/visibilité derrière le numéro 1 de l’Open Source Red Hat.

Le chantier pour passer Ansible sur Python 3 est en cours et une tech preview du support de Python 3 est disponible depuis Ansible 2.2.

Le dernier point concerne la direction que prend Ansible notamment en développant toute la partie réseau que ce soit au niveau des modules (networking modules) et du fonctionnement de Ansible. Je vous invite à lire deux articles sur ces sujets sur le blog de Ansible (1, 2).

Toujours plus de modules

Voici une short list des nouveautés qui ont attiré mon attention sur les deux dernières versions majeures. Je vous invite à consulter le changelog complet de chaque version pour voir les nombreux autres modules ajoutés.

Changelog Ansible 2.3 :

Changelog Ansible 2.2 :

Et Windows

J’attendais de voir l’évolution de l’automatisation des environnements Windows sur Ansible et c’est (enfin) mature :

# On exécute PowerShell en tant qu'administrateur (Clic droit puis Exécuter en tant qu'administrateur)
# https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
# ConfigureRemotingForAnsible.ps1 est placé à la racine du C:\\
Set-ExecutionPolicy Unrestricted -Force
cd C:\\; .\\ConfigureRemotingForAnsible.ps1
Set-ExecutionPolicy Restricted -Force
Remove-Item ConfigureRemotingForAnsible.ps1; exit

J’ai configuré tous mes serveurs Windows et je vais maintenant m’intéresser aux tâches que je peux automatiser.

Gravatar de blog-libre
Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Articles similaires