PROJET AUTOBLOG


alterlibriste

Site original : alterlibriste

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Podcasting : L'apéro des papas manchots

vendredi 24 mars 2017 à 14:12

Il y a 4 mois naissait un nouveau podcast sur le libre : l’Apéro des papas manchots.

À ce jour 5 épisodes au compteur, pourquoi ne pas en avoir parlé plus tôt ?
Eh bien, parce qu’avant de présenter en détail un podcast, je veux être sûr qu’il ne s’arrêtera pas au deuxième épisode (ça c’est bon), mais aussi parce que j’aime bien avoir une idée précise de son identité, ce qui nécessite aussi au moins trois épisodes, et enfin, parce qu’il faut qu’il y ait une certaine maturité et stabilité afin de ne pas recommander quelque chose qui ne sait pas trop dans quelle direction il va et sous quelle forme, ou avec des problèmes techniques récurrents qui pourraient rebuter un poditeur peu indulgent. Mais après un début un peu chaotique, ça commence à prendre forme.

Le concept de départ est relativement simple : des utilisateurs de GNU/Linux pour leur utilisation familiale (des papas manchots) discutent de leurs expériences, de quelques actus et de leurs avis sur des logiciels libres qu’ils utilisent. Apéro, pour un clin d’œil à mi-chemin entre feu-Parole de Tux et l’Apéro du Captain, et surtout la bonne humeur de discuter sans se prendre au sérieux autour d’une bière... ou d’une eau plate pour les plus sobres.

Initié par Donkluivert qui avait déjà sévi dans feu-Parole de Tux et dans BlogueLinux en tant qu’invité et surtout en tant que pilier de feu-NipSource, celui-ci a pour but principal de partager sa passion du podcast en produisant quelque chose qui se veut détendu et abordable aux débutants ou utilisateurs peu avancés. L’autre membre fondateur du podcast est John Gecko, le roi de la claquette, qui aime à raconter ses expériences plus ou moins réussies avec les jeux Linux sur Steam et partage ses découvertes sur la ligne de commande.

Plusieurs épisodes ont rencontré des problèmes de son qui ont malgré tout été corrigés au mieux notamment grâce à l’aide de Patrick de BlogueLinux.ca qui les a pris sous son aile pour les héberger. Lorsque l’oiseau pourra quitter le nid, ce sera bien qu’il devienne indépendant car la cible de ce podcast est nettement moins expérimentée que ceux qui écoutent avec passion nos canadiens préférés, même si l’écoute des deux n’est pas antinomique.

Pour les épisodes 3 et 4, Morgan, du podcast Alpinux, a participé et donné une autre dimension aux émissions en parlant de tous les sujets qui l’intéresse. Il est probable qu’il y participe régulièrement et que d’autres invités viennent partager leurs expériences et leur apéro.

Le format semble s’être stabilisé autour de 2h avec une fréquence mensuelle. Tous les avis sont les bienvenus et l’équipe tient compte des remarques des auditeurs en lisant les commentaires. Alors, pour tous les manchots, papa ou pas, qui aiment entendre parler de logiciels libres et veulent ajouter un flux dans les podcasts qu’ils écoutent, c’est par ici !

Nouvelles de la podcastosphère libriste francophone - Printemps 2017

lundi 20 mars 2017 à 17:24

Un petit bilan trimestriel des évolutions dans le monde des podcasts touchant de plus ou moins près au monde du libre francophone et à l’évolution du monde numérique :

Toutes ses références sont à retrouver sur ma page statique mise à jour aussi régulièrement que possible.
Comme je l’ai déjà dit et le répète, certains contenus ne sont pas directement liés au libre (mais tous sont sur le numérique) et tout ce qui existe n’est pas répertorié notamment ce qui a spécifiquement trait au développement ou à la sécurité.
Étant donné que je suis moi aussi un papa manchot, je m’intéresse plus particulièrement aux usages domestiques des outils libres et numériques, ainsi que leur évolution dans la société.

Un lecteur audio avec Kodi et Raspberry

lundi 13 mars 2017 à 19:01

Mon raspberry pi, premier du nom, commençait à prendre la poussière sur une étagère quand je suis tombé sur une discussion bien intéressante sur Diaspora* pour en faire un lecteur de musique, j’avais tout ce qu’il faut, juste à tout réunir.

DSCF2479.png
Elle était belle l’époque où on se faisait soi-même son boîtier, ici découpé dans une pochette photos

J’ai acheté mon pi il y a 3 ans, initialement pour en faire un lecteur vidéo pour mon rétro-projecteur. La reconnaissance de DVD n’étant pas toujours au top, je l’ai finalement remplacé par un lecteur DVD portable dont l’écran n’a pas aimé la chute qu’il a subit. J’ai ensuite utilisé le raspberry pour me faire la main sur l’auto-hébergement. Comme il a été remplacé par quelque chose d’un peu plus puissant et robuste, il attendait une autre utilisation.

D’un autre côté, j’ai une bibliothèque musicale numérisée de plusieurs dizaines de Go qui ne faisait pas grand chose. J’avais déjà expliqué dans un précédent billet que je n’achète que de la musique sous forme de CD (so nineties !), cependant, je les encode dans mon PC pour pouvoir éventuellement les écouter sur un lecteur numérique et aussi pour en faire une sauvegarde (je me suis déjà fait piquer une pochette avec mes disques préférés du moment, pas cool). J’ai aussi quelques albums de musiques libres ou de CD empruntés en médiathèque. Cependant, je n’écoute quasiment jamais de musique en étant sur l’ordi parce que ça me perturbe quand je travaille ou au mieux, je ne l’entends pas. Par contre, le fait de pouvoir écouter tout ça sur ma chaîne (notamment en aléatoire) lorsque l’on est en train de cuisiner ou de manger me semblait bien intéressant.

Je sais qu’il existe des projets audio spécifiques et parfois très poussés sur Raspberry, soit en tant que serveur (pour écouter sa musique sur n’importe quel appareil), soit en tant que lecteur sur une chaîne ou un ampli. Mon but n’était pas de me plonger dans une configuration compliquée et même sans ça, il m’a fallu une dizaine de jours pour tout paramétrer comme je le souhaitais.

Sur le pi, j’avais déjà Kodi. J’avais un temps utilisé OpenElec (devenu LibreElec) qui n’est fait que pour ça mais je préfère avoir un OS qui peut faire plusieurs choses et donc une Raspbian qui fait ça aussi bien (voici un bon tuto pour faire ça de zéro). Ma bibliothèque musicale est sur mon PC principal qui contient tous les fichiers qui doivent être régulièrement sauvegardés. Il me fallait donc en rendre au moins une partie disponible sur un espace suffisamment grand et disponible même lorsque le PC est éteint. Mon serveur qui contient déjà un répertoire en partage NFS afin d’être accessible depuis les différentes machines était tout désigné. Restait ensuite à brancher le raspberry sur le réseau, de lui donner l’accès à ce répertoire, de faire un peu de ménage sur toute la partie serveur qui ne servait plus (Apache, TT-RSS, MariaDB, etc.), de le brancher sur la chaîne et sur le courant.

Lorsque j’ai réfléchi à tout ça, je me suis dis que j’aurais aussi bien pu faire ça directement depuis le serveur déjà en place (et concrètement, je n’avais besoin que d’installer Kodi et tirer un fil audio jusque la chaîne) pourtant je n’ai résolument pas fait ce choix. Il aurait très bien pu tenir la charge supplémentaire mais en plus d’utiliser le raspberry qui ne servait plus, je voulais pouvoir l’éteindre (j’ai ajouté un interrupteur sur le branchement de l’alimentation) lorsqu’il ne servait pas et surtout éviter de donner une porte d’entrée (failles potentielles) sur le serveur qui fait tourner des services dont j’ai besoin au quotidien.

Une fois tout cela installé, il me restait à trouver les moyens de commander tout ça sans écran et sans clavier. J’avais déjà testé le téléphone comme télécommande sur Kodi sans en explorer toutes les possibilités. Sur Android, Kodi Remote (Kore de son petit nom) est un must have que j’ai adopté sur la tablette du gamin. J’en étais presque à me tâter de passer à LineageOS sur mon Open C et quitter Firefox OS, mais il semble que c’est quand même un peu lourd pour la bête.

C’était sans compter sur l’appli équivalente FoxMote que j’ai eu un peu de mal à paramétrer (il faut autoriser le contrôle à distance par des programmes sur d’autres systèmes en plus du contrôle à distance par des programmes sur ce système). Il faut aussi penser à faire une mise à jour de la bibliothèque à chaque démarrage une fois indiquée la source des fichiers musique. En plus des divers appareils mobiles, un accès par interface web est aussi possible pour piloter ça depuis le PC (192.168.0.X:8080, une fois autorisé l’accès par http dans l’onglet serveur web de Kodi/Système/Services).

Pour le bon fonctionnement de ces diverses télécommandes, il faut aussi assigner une adresse IP locale qui sera toujours la même en paramétrant les baux DHCP permanents de son fournisseur d’accès internet sinon à chaque démarrage il prendra une IP différente (j’avais déjà expliqué ça pour l’installation de tt-rss sur un raspberry).

Bref, une expérience bien intéressante qui utilise tout le matériel et les expérimentations faites précédemment, il n’y avait plus qu’à réunir tout ça. En avant la musique !

Go fsck yourself !

lundi 6 mars 2017 à 21:43

Suite à mon dernier sauvetage de système de fichiers, j’ai un peu médité sur la question et me suis demandé si tout ça était vérifié régulièrement. Je me suis surtout souvenu que lorsque j’étais sous Ubuntu, il y a bien 4 ans, il y avait tous les 30 montages une vérification du système de fichiers qui tombait forcément mal, juste au moment où on avait besoin urgent du PC.

Mais plus de tout ça depuis de nombreuses années. Alors je fais mes petites recherches et m’aperçoit en faisant un :
$ sudo tune2fs -l /dev/sda1 (à adapter à la partition que l’on souhaite vérifier)
que j’avais certaines partitions montées plus de 1000 fois et jamais vérifiées depuis plus de 2 ans (date de la dernière installation du système).
Les paramètres mount count étaient à -1 (c’est le nombre maximal avant vérification, donc jamais) et check interval à 0 (temps entre chaque vérif, jamais aussi).

Ma première réaction a été de me dire que Debian laissait gérer ça par ses power users contrairement aux distributions user friendly qui prenaient soin de tout paramétrer au mieux pour leurs utilisateurs débutants. Que nenni, Ubuntu n’est plus pourvu de cette vérification non plus. Ma deuxième réaction a été de me dire que SytemD, dans sa toute puissance, avait pris en charge cette tâche ingrate. Pas plus, en creusant un peu, on se rend compte que Wheezy et Ubuntu 12.04 étaient déjà exemptés de vérification.

Quand on cherche pourquoi le fsck a été désactivé, on tombe surtout sur des tutos pour le désactiver mais aussi sur tous les wikis qui disent que ce n’est pas bien et qu’il vaut mieux qu’il y ait une vérification au moins tous les 50 montages. De temps en temps, on tombe sur un pékin qui se demande comme moi pourquoi c’est devenu comme ça... et je n’ai trouvé aucune réponse claire, mais surtout aucune explication officielle.

Un truc qui emmerdait tout le monde et qui devait surtout être fait au risque de devoir faire pénitence en se fouettant avec du câble RJ45 est disparu du jour au lendemain sur toutes les distributions sans aucune explication officielle (enfin si quelqu’un peut me l’apporter, je suis preneur) et tout va très bien madame la marquise. Mais de deux choses l’une : soit c’était inutile, soit on fait comme si tout va bien se passer.

Bon après, pas de quoi s’alarmer non plus, on voit au démarrage que les volumes montés sont clean et si la machine s’est éteinte à la sauvage (hard reboot, coupure de courant ou autre), on voit passer des lignes comme quoi le dernier arrêt ne s’est pas bien passé et que le ménage est en train d’être fait pour que tout soit d’aplomb.

Parmi les explications, on trouve en vrac : ça arrivait à un mauvais moment (d’ailleurs il y a eu un projet pour que ce soit fait à l’extinction plutôt qu’au démarrage), on ne vérifie plus que s’il y a eu un problème, un système de fichier journalisé n’a plus besoin d’être vérifié, ...

En général, ceux qui, comme moi, ont posé la question ont fait une vérification (elle est beaucoup plus rapide depuis ext4) et, dans le doute, remis les paramètres de vérification régulière de la manière suivante (tous les 50 montages ou 2 semaines) :
$ sudo tune2fs -c 50 -i 2w /dev/sdaX

Ainsi, au cours de mes recherches, j’ai trouvé que le fsck était originellement remplacé par un mot plus vulgaire quand le système était dans les choux et qu’il était de mise de dire "go fsck yourself" pour réparer. Chose que l’on a maintenant à faire soi-même si on veut vérifier que tout va bien.
Reste surtout à mettre à jour internet qui regorge de directives du passé.

Rendre Debian stable moins obsolète

lundi 27 février 2017 à 17:24

Il n’est pas rare de lire que Debian Stable est rapidement obsolète et de nous sortir les quelques versions de retard du noyau, de LibreOffice et du navigateur. Pourtant, rien ne nous empêche d’adopter des versions plus récentes et de tordre le cou à cette critique.

Entendons-nous bien, Debian stable est stable comme le rock tant que l’on reste uniquement sur la branche stable. Elle a un cycle assez long d’environ deux ans qui permet d’avoir des versions de logiciels relativement à jour à sa sortie mais qui commencent à dater un peu au bout des deux ans.

Pour une utilisation en production (serveur, postes de travail critiques), cela ne se discute pas. À part quelques mises à jour de sécurité, qui peuvent être faites automatiquement, rien ne changera et donc tout restera stable pour une maintenance quasi-nulle et les utilisateurs peu enclins aux changements ne s’en porteront que mieux.

Pour une utilisation domestique, si l’on souhaite évoluer, avoir les derniers drivers ou que l’on a du matériel un peu récent, il devient intéressant d’avoir des versions plus à jour. Ici, s’ouvrent plusieurs voies : passer sur la branche testing qui préfigure la future stable, ou la branche sid qui équivaut à une rolling release. Le risque n’est pas énorme, mais présente quelques inconvénients incompatibles avec le choix d’une version stable, à savoir, installer et être tranquille pour un ou deux ans :

Pourtant, il y a plusieurs moyens d’avoir des versions plus récentes de paquets sans quitter l’environnement Debian. Je ne parlerai pas ici de jouer au funambule entre les différentes branches en allant chercher ce qui nous intéresse grâce à l’apt-pining, mais simplement l’ajout de certains dépôts, notamment celui des backports qui contient les paquets présents dans testing et rétro-portés pour la branche stable.

La chose est simple puisqu’il suffit, en éditant le fichier :
sudo nano /etc/apt/sources.list
d’ajouter la ligne suivante (contrib et non-free étant à la discrétion de chacun selon la volonté ou pas d’utiliser du 100% libre) :
deb http://httpredir.debian.org/debian jessie-backports main contrib non-free
Une fois le apt update de rigueur réalisé, cela n’aura rien changé dans les update des paquets, il faut préciser que l’on veut un paquet issu de backports pour qu’il soit installé de la manière suivante :
sudo apt install -t jessie-backports libreoffice

Voilà la manière de passer de la version 4.3 qui était la version stable à la sortie de Jessie à la version 5.2 disponible au moment de l’écriture du billet (la 5.3 sortie récemment n’étant encore que dans le dépôt experimental) ce qui est quand même plus récent pour ceux qui souhaitent profiter des apports faits sur les dernières versions.
Pendant qu’on en est à rajeunir la logithèque, les paquets libreoffice-style-sifr (déjà présent dans Jessie) et libreoffice-style-breeze (dans les backports) qui ne sont pas installés par défaut apportent des thèmes un peu plus modernes aux icônes un peu vieillissantes des thèmes Tango et Galaxy (Outils/Options/Affichage/Style d’icônes).

Quoi mettre à jour d’autre ?

Voilà pour l’aperçu des moyens de garder une Debian Stable plus à jour et avoir un meilleur compromis entre stabilité et nouveauté pour patienter avant la sortie de Stretch prévue pour l’été.