PROJET AUTOBLOG


Blog-Libre

Site original : Blog-Libre

⇐ retour index

Accepter et entendre la critique dans le libre

dimanche 1 juillet 2018 à 07:00

Je n’aime pas qu’on me dise comment je dois utiliser un outil/logiciel/produit. Si il est bien conçu/pensé alors son utilisation, sa prise en main sera simple et naturelle. Elle aura du sens.

Il est nécessaire de fournir une documentation évidemment. C’est une bonne chose de présenter, argumenter, justifier les choix effectués (fonctionnement, technos, architecture, UI/UX…) : Pourquoi on a fait ça, comment on l’a fait. Pourtant il y a une chose cruciale à ne pas oublier : Une grosse partie des utilisateurs ne lira pas la doc, se fout complètement de vos problématiques et justifications. Ils veulent un truc qui tombe sous le sens, qui soit pratique/utile pour eux, qui fonctionne de manière simple. Si l’utilisateur pense avoir affaire à un outil/logiciel/produit mal conçu, vos arguments et justifications n’en feront pas quelque chose de bien conçu. L’utilisateur adaptera peut-être son comportement, sera moins critique, plus compréhensif car il aura compris le pourquoi/comment mais cet outil/logiciel/produit demeurera mal foutu dans son esprit.

Je vois régulièrement ça dans le logiciel libre : “Bon c’est mal foutu mais voilà l’explication”… mais ça reste mal foutu ! C’est comme si on avait intégré/accepté l’idée que le logiciel libre est imparfait, mal fini. C’est une véritable culture. De là découle le très fameux “c’est un logiciel libre, contribue”. Non ! Il faut accepter, entendre la critique. C’est bien plus constructif que tenter une justification.

Il faut de l’empathie pour comprendre, c’est-à-dire se mettre à la place de l’autre (ici l’utilisateur). L’utilisateur dit “c’est mal foutu”, on lui explique que non et pourquoi puis on lui rappelle/rétorque “tu peux l’améliorer, tu peux contribuer”. Il est intéressant de souligner que souvent on lui explique qu’il a tort en justifiant un choix technique par exemple alors que l’utilisateur donne seulement/simplement son ressenti.

J’aime bien la blague (certains appellent ça un argument) de la possibilité de contribuer. Quiconque a déjà contribué sait que c’est loooooooiiiiiiiinnnn d’être simple. En vrac complet : 1/ La doc est en Anglais, on communique en Anglais, on remonte les issues en Anglais 2/ Prenons GitHub. Il faut connaître (de “simples” utilisateurs ne connaissent pas), il faut avoir un compte, il faut savoir créer/remonter une issue ou un bug 3/ Il faut savoir. Combien d’utilisateurs sont à des années-lumière de pouvoir juste expliquer de manière compréhensible le problème rencontré ? 4/ La contribution simple, systématique, rapide, on n’est pas loin du mythe. Une pull-request peut rester des semaines/mois sans être pushée dans le projet, évidemment elle peut être rejetée. Ce n’est pas parce que le logiciel est libre que les contributions sont systématiquement acceptées et que l’accueil est chaleureux (il est souvent inexistant). Pour la simplicité, voir les points précédents

Oui il est possible de contribuer en théorie, dans la pratique c’est nettement plus compliqué. L’utilisateur signale juste un problème, il n’est pas dans une démarche/réflexion pour contribuer et même si il l’était, le chemin restant avant qu’il le fasse est long et difficile.

Une majorité d’utilisateurs est dans une position de consommateurs. L’utilisateur n’est pas satisfait, il le dit. Le sympathisant du libre, le contributeur doit se mettre à son niveau, comprendre son besoin. Il doit lui tendre la main sinon l’utilisateur restera déçu, impuissant et incapable d’utiliser l’outil/logiciel/produit pour finir par aller voir ailleurs.

Certains penseront que ce n’est pas une grosse perte. Je cite une devise Framasoft : “Parce que ce serait l’une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d’autre que du code”.

Le forum des bons pères de famille

samedi 30 juin 2018 à 07:00

Je fais partie de la communauté des blogueurs parlant du Libre. Le mot communauté est probablement trop fort, c’est davantage de la camaraderie. Les blogueurs qui s’adressent au grand public pas (uniquement) à des techniciens/pros, qui publient en essayant d’être accessible/vulgarisateur, ça commence à être dur d’en trouver.

Chaque blogueur est indépendant, il fait son truc dans son coin, il parle de ce qu’il a envie de parler. Il est difficile de le convaincre de rejoindre une équipe car il n’y verra quasiment aucun avantage : Moins de liberté, plus de contraintes, outil de publication (site ou blog) imposé et unique. Il est cependant nécessaire qu’on se serre un peu tous les coudes, blogueurs et lecteurs. Le risque bien réel, c’est qu’il ne reste plus de blogueurs ou vraiment peu de thèmes traités.

Cyrille tient le forum des bons pères de famille. Dans mon esprit ça renvoie à une certaine responsabilité, à un minimum de vécu. On y parle informatique, Libre, éducation, vie courante. C’est respectueux, on s’y écharpe pas pour une différence de point de vue (genre Lignux), on partage des liens et des astuces. C’est un territoire neutre pour échanger, partager, poser des questions, lancer des réflexions. Un endroit où lecteurs et blogueurs peuvent se croiser, où on peut s’entraider, briser la glace.

Denis, Damien, Alterlibriste, Iceman, Odysseus y traînent, je vous invite à venir, vous savez où me trouver ;)

En équipe

vendredi 22 juin 2018 à 17:30

La fatigue, la solitude, la lassitude, le manque de temps, des priorités plus hautes, la perte de motivation guettent le bénévole. Les remerciements et encouragements sont rares, les salutations ont disparu depuis longtemps.

Les équipes qui fonctionnent sont soit soudées c’est-à-dire que les individus sont “proches” soit contraintes comme dans le monde de l’entreprise. Un bénévole n’ayant aucune contrainte autre que sa propre volonté abandonnera projet/équipe au bout de quelques frictions seulement.

Aujourd’hui chacun porte son projet dans son coin, chacun réinvente sa roue. Tout seul on va plus vite, ensemble on va plus loin et justement on n’arrive plus à aller bien loin. Individualisme, disparition d’une certaine fraternité/solidarité, croyance qu’on peut se passer d’autrui, respect nécessaire devenu optionnel. Chacun sa gueule.

Je suis fatigué en ce moment par les façons de faire, de dire les choses autour de moi. Comme un déficit d’attention et d’empathie pour l’autre. Les bons et les méchants, ceux qui ont raison et ceux qui ont tort, les sachants et les imbéciles, les privilégiés et les minorités. Autant de barrières érigées avec des mots et des idées pour empêcher de se rejoindre.

Montrez que vous avez du cœur plus que des arguments, pardonnez plutôt que prouver, écoutez au lieu de parler, respectez l’autre avant d’exiger qu’il vous respecte.

Je ne suis pas sociable, très indépendant, solitaire par nature mais je ne sais jouer qu’en équipe parce que sans les copains derrière, sans les proches et les gens qui poussent, plus de raison d’avancer. Toutes les raisons d’arrêter.

Je dédie ce billet à Alterlibriste – meilleur vieux croûton à la retraite – qui titre Que reste-t-il du logiciel libre ? Nous ! Il ne reste plus grand monde mais on va se serrer les coudes, j’espère.

Nix ou la gestion des paquets en question

vendredi 15 juin 2018 à 10:00

A1 est mon dealer officiel d’outils et d’articles intéressants, il m’a rappelé l’existence de Nix. J’avais justement mis dans un coin (éloigné) de mon esprit de revenir sur Nix et NixOS. L’article présent n’ayant pas pour but de vous présenter NixOS, je vous invite à consulter cet article sur le sujet.

Je vais uniquement vous parler de son gestionnaire de paquets : Nix. Il a notamment la particularité de pouvoir s’installer sur n’importe quelle distribution facilement (Debian 8 minimum, Ubuntu, Fedora… même si actuellement à mon grand regret ce n’est pas possible sur Raspbian). Commençons par vous mettre le pied à l’étrier pour l’utiliser, après on causera.

Installation et utilisation

Installation
bash <(curl https://nixos.org/nix/install) Pas de sudo avant, il demande si besoin. Il va créer un dossier nix à la racine donc /nix

nix-channel
nix-channel --list Même principe qu’un sources.list
nix-channel --add https://nixos.org/channels/nixpkgs-unstable
nix-channel --remove nixpkgs
nix-channel --update

nix-env
nix-env -i ranger ncdu # -i, --install
nix-env -e ranger # -e, --uninstall
nix-env -u ranger # -u, --upgrade package
nix-env -u # Upgrade all packages
nix-env -q # View installed packages
nix-env --rollback

Quelques commandes pour la maintenance
nix-channel --update && nix-env --upgrade Perso j’utilise alias nn='nix-channel --update && nix-env --upgrade'. Pour transposer à apt, ça correspondrait à apt update && apt upgrade
nix-env --list-generations # Print a list of all the currently existing generations for the active profile
nix-env --delete-generations old
nix-collect-garbage -d # Deletes all old generations of all profiles is a quick and easy way to clean up your system

C’est la base avec nix --help et nix search nomdupackage, la doc ici, deux articles (1, 2) très intéressants sur LinuxFr.org.

Pour être sûr du gestionnaire de packages que vous utilisez, which nomdupackage. Si ça pointe vers /nix l’application est gérée par nix. Précisons c’est pour une utilisation mono-utilisateur, pour du multi-user c’est plus compliqué, ça ne fonctionne pas encore pour l’utilisateur root.

Je ne rencontre aucun souci sur les packages suivants : fzf htop keychain ncdu peco ranger ripgrep vagrant zsh. Ça fonctionne pour firefox mais pas virtualbox chromium. Je songe à installer toutes mes applications en passant par Nix, le point négatif étant l’espace consommé.

Mais pour quoi faire ?

Nix permet d’installer des applications sans droit root, l’application est alors uniquement disponible pour l’utilisateur courant.

Cas d’utilisation N°1 : J’ai un conflit de dépendances avec mon gestionnaire de paquets (apt), je ne peux pas installer la dernière version de trucmachin => nix-env -i trucmachin. On bypasse le gestionnaire de paquets
Cas d’utilisation N°2 : Je veux une version plus récente que le truc qui a 4 ans sur ma Debian 8, nix-env -i ranger ncdu terminator. On bypasse gestionnaire de paquets et version de la distrib
Cas d’utilisation N°3 : J’ai peur de ce nouveau horrible Firefox 58 (compatibilité des extensions par exemple…), nix-env -i firefox on teste puis si ça le fait pas nix-env --rollback. C’est plus secure et plus souple que le gestionnaire de paquets

Vous voyez l’intérêt et le potentiel ? Vous vous dites purée je vais m’éclater sur ma vieille Debian et même sur Ubuntu, à moi les dernières versions sans rien casser (ni ajouter de PPA), en pouvant rollback et en m’emmerdant plus avec des problèmes de dépendances (même plus besoin d’apprendre la syntaxe pour utiliser apt, yum ou dnf). Dieu vous a ouvert les portes du paradis et embrassé sur le front, alléluia !!

Oui mais…

Les utilisateurs se focalisent sur ce qu’ils doivent utiliser et comment (apt par exemple) mais ne s’interrogent pas sur le pourquoi. On allume notre ordinateur pour l’utiliser ou pour galérer à installer des packages et faire leurs mises à jour ?

Avec une distribution des packages dans des écosystèmes différents (ppa pour Ubuntu, pip pour Python, npm pour Node, container pour Docker, etc.), l’utilisateur se retrouve à devoir utiliser, apprendre, comprendre 4 outils au lieu de 1. Je cherche à en utiliser le moins possible idéalement 2, avec Nix j’ai contourné le problème sans le résoudre. Aucun outil n’est parfait, citons nix-env -i chromium qui ne fonctionne pas notamment.

On ne répond toujours pas au besoin et à la problématique de l’utilisateur de pouvoir installer un paquet récent simplement, sans problème de dépendances, peu importe l’écosystème. Demande déplacée, rêve éveillé, problème insoluble ?

Quelques réflexions autour de l’externalisation des sauvegardes

samedi 9 juin 2018 à 09:00

Sebsauvage a publié sur son wiki sa recherche d’un petit cloud perso pour y stocker des données personnelles (2 To).

Une majorité d’entre nous fait ses sauvegardes sur un disque dur interne/externe ou sur un NAS. Données et sauvegardes sont situées au même endroit physique, il peut arriver un événement rare (mais pas impossible) comme un incendie ou un cambriolage => gros fail. On en conclue qu’on a besoin d’externaliser nos sauvegardes.

Identifier et formaliser

Il faut vraiment prendre le temps d’identifier et formaliser. Prenons le cas de Sebsauvage.

Public visé : Informaticien
Ressources et moyens : Connaissances en informatique et Lignux, usage de BorgBackup, prêt à payer pour son besoin
Contexte : Personnel pas professionnel (environnement), pas urgent (délai), assez important (priorité), actuellement chez hubiC (analyse de l’existant)
Besoin : Avoir un système de sauvegarde efficace (et pas simplement “faire des sauvegardes”) pour 2 To de données
Corollaires : Identifier les outils pour effectuer des sauvegardes, restaurer les données, tester la restauration des sauvegardes, externaliser les sauvegardes
Contraintes : Coût limité (typiquement pas plus de 10 euros par mois), accès par protocole ouvert (ssh/sftp/ftp/webdav/rsync…)
Tolérance : Se moque des performances et de la disponibilité
Idéal : Le moins coûteux possible (argent et temps), principe KISS
Inconnus : Pas d’information sur la volumétrie de données à envoyer ni sur le planning (récurrence/fréquence) des sauvegardes ni sur leurs utilisations

Ce que je viens d’écrire est relativement simple mais on a grandement précisé les choses via 4 axes :

On fournit une solution par rapport à un public, des ressources et des moyens à disposition, un contexte et un besoin. Sauvegarder 50 Go ou 2 To, ce n’est pas le même besoin donc le même problème à résoudre. De même un débutant n’aura pas les mêmes connaissances en informatique qu’un informaticien, une entreprise n’aura pas les mêmes moyens qu’un particulier. Il est nécessaire d’adapter la solution à chaque cas.

On cherche à faire des sauvegardes (niveau 1) puis ensuite à avoir un système de sauvegarde efficace (niveau 2). Il y a une logique de progression mais aussi de priorités. Avant de penser à externaliser, il faut que votre processus “faire des sauvegardes” soit rodé et satisfaisant. Je vous renvoie à la règle des 3-2-1.

Considérer les solutions

Je ne vais me concentrer que sur les principaux inconvénients d’externaliser ses données personnelles dans le cloud en me basant sur le cas de Sebsauvage (je vous invite fortement à lire son article avant les lignes ci-dessous) :

A présent je vais proposer une autre solution que je vais nommer “solution locale” :

Inconnus, données actives et inactives

Il y a potentiellement un gros fail dans cette solution, ça correspond aux inconnus, on ne connaît pas l’utilisation de ses données. Sebsauvage a-t-il besoin de restaurer/récupérer régulièrement les données de ses sauvegardes ?

On va différencier 3 types de données :

Ce que l’on vient de faire là, c’est analyser plus finement le cas d’utilisation et les besoins de Sebsauvage. On les a passé sous une loupe et on a augmenté notre champ lexical : fréquence (régulièrement, tout le temps, une fois de l’an ?), accès (rapide, lent, de partout ?), utilisation (lecture, écriture, partagée ?).

Mon besoin

J’ai sensiblement le même besoin que Sebsauvage à la différence notable que j’ai besoin d’inclure une synchronisation des données.

J’ai un pc portable (pour mes déplacements/interventions), un pc fixe perso à mon domicile, un pc fixe pro au bureau. Lorsque je travaille quelque part, j’ai besoin de récupérer les données sur les autres postes. ATTENTION UNE SYNCHRONISATION N’EST PAS UNE SAUVEGARDE. J’écris un texte dans un document, il se synchronise sur les autres postes, je supprime ce texte, il se synchronise sur les autres postes, je perds donc mon texte. Dans le monde proprio l’outil de synchronisation par excellence s’appelle Dropbox, dans le monde libre c’est Syncthing dont le fonctionnement est distribué. Syncthing a mauvaise presse pour deux raisons : 1/ Sa relative complexité (que je confirme) liée au fait que c’est un outil pointu, puissant, souple 2/ Les ressources qu’il consomme, ça tombe bien c’est réglé depuis quelques semaines.

A présent ma solution nommée sobrement “solution maison” :

Votre besoin

Je ne viens pas de vous donner une solution générique, chaque cas est particulier. En revanche je vous ai fourni les informations, les termes, les pistes, le cheminement si vous voulez apprendre, comprendre…

A noter que pour aller au fond des choses, on devrait utiliser des outils de sauvegarde différents. Borg d’un côté, restic de l’autre prévenant ainsi une erreur humaine ou un bug sur l’un des deux outils. On peut évidemment mixer les solutions présentées dans ce billet, c’est même recommandé pour appréhender les différentes possibilités.

J’ai pris des libertés sur certains concepts car j’essaie de vulgariser, merci de ne pas m’injurier dans les commentaires ;)