Compte tenu des dispositions prises par le gouvernement concernant le COVID-19, notamment sur la limitation de la propagation du virus dans les espaces publics, la MJC Châteauvert a pris la décision de fermer ses portes au public dès le Lundi 16 Mars 2020 et ce jusque nouvel ordre. De ce fait, l'évènement Libre en Fête organisé par G3L est annulé.
J’ai terminé ma migration de Mint vers Debian bullseye/sid. Je suis sur ce dernier depuis 2 mois et demi sur mon pc portable (dual-boot : Mint et Debian), 1 mois et demi sur mon fixe. L’heure de vous faire un petit retour d’expérience et vous expliquer pourquoi j’ai changé de crèmerie.
Après Mint
J’étais extrêmement satisfait de Mint, pour moi elle surclasse Ubuntu, a un développement actif et sain, amène de nouvelles idées. J’ai réellement utilisé 3 distributions desktop dans ma vie : Xubuntu, Mint Xfce, Debian Xfce. Je recommande lourdement et sans aucune hésitation Mint. Lorsque j’ai décidé de remplacer ma distribution, ma shortlist contenait encore Mint ^^
Mais alors pourquoi ce changement ? La réponse est simple : Moi.
Lorsque je suis passé à Mint, j’ai commis une grosse erreur. Je savais qu’elle était basée sur Ubuntu, je la voyais faire de meilleurs choix, en réalité elle est basée sur Ubuntu **LTS**. Énorme différence pour moi, j’aime la nouveauté, les versions récentes des outils que j’utilise. Je suis arrivé sur Mint (basée sur Ubuntu 18.04 LTS) en septembre 2018, je n’ai rien vu… courant 2019 alors que je réinstallais des serveurs Debian en Buster au boulot, ça a commencé à sentir la naphtaline. J’avais des paquets moins récents que sur Debian Buster. Intenable pour moi, il fallait trouver une solution.
Une seconde raison a été ma volonté de retourner aux sources : Debian. J’ai fait quelques articles où je critiquais Ubuntu, j’étais sur Mint mais avec des vieux paquets, je bosse sur Debian au boulot. Quel intérêt de rester sur les filles ? Pourquoi ne pas retourner sur la distribution mère ? Une envie de tester, de voir si il me manquait des choses sur Debian.
Enfin la dernière raison est que Debian est ma distribution de cœur. La plus en accord avec « moi ». Je suis à la maison, chez moi. Je n’ai pas besoin d’accepter les idées de merde de Canonical/Ubuntu, Debian ne propose pas vraiment sa « vision » du desktop Linux. On construit réellement, on modèle son foyer chez Debian (relire Architecte). Avec Ubuntu/Mint on me tenait encore la main, les plans étaient déjà largement dessinés, la cohérence (réussie souvent) de l’ensemble restait malgré tout imposée. Sur Debian j’ai refait toute la déco, j’ai chiffré manuellement mon /home, j’ai choisi mes fondations récentes voire trop (bullseye/sid). Cette construction est définitivement la plus proche de moi et mes goûts.
Debian bullseye/sid
Lorsqu’on fait cat /etc/debian_version sur un serveur Debian « Buster » 10 alors on obtient « 10.3 » actuellement. Sur mon pc on obtient « bullseye/sid », je trouve ça amusant, je ne savais pas que Debian était capable de gérer/afficher cette particularité.
Les « bonnes » surprises sont peu nombreuses car je considère beaucoup de « qualités » comme implicites :
Les paquets sont très récents, pas besoin d’aller chercher plus loin la « fraîcheur »
Je craignais qu’il me manque des outils/paquets sur Debian, aucun manque
Debian est brut de décoffrage, c’est fourni moche de base. Je trouve ça énorme de dire ça, tout le monde sera d’accord pourtant. D’un autre côté cela force à creuser ce que l’on veut, nos goûts, faire des choix
J’étais curieux de voir la légendaire stabilité de Debian en « bullseye/sid » : J’ai eu jusqu’à maintenant des freezes, quelques comportements étranges, Chromium qui plante sauvagement. Je rappelle que j’utilise 60h par semaine mes postes sur Debian, je travaille dessus. Debian est certainement très stable mais si tu veux du stable, tu restes sur stable ha ha. Je précise que je voulais du « bullseye/sid », j’y reste, j’en suis satisfait
J’ai redécouvert le formidable outil apt-listbugs indispensable en bullseye (testing) ou bullseye/sid. Pour connaître les bugs sur un paquet apt-listbugs list chromium, sur tous les paquets apt-listbugs list $(dpkg --get-selections | awk '/install/ {print $1}')
Je vais plus loin dans ma compréhension et mon utilisation de Debian : Le pinning, le suivi et les corrections des bugs, la sortie des paquets
Peu de choses à en dire finalement, j’ai fait que des distribs en .deb, je reste en territoire connu/voulu. En insatisfait éternel, je regrette une stabilité totale (que j’avais sur Mint) mais ça ne se conjugue évidemment pas avec des paquets frais. Niveau maintenance je n’ai pas plus de travail à effectuer que sur Mint, je conserve ma gestion des mises à jour.
L’ultime qualité d’un outil est de se faire oublier. Hormis quelques instabilités, j’oublie Debian.
Entraide et partage
Avec le temps j’ai appris de mes erreurs, j’avais préparé ma migration notamment le pinning et mon sources.list mais j’ai tenu à vérifier mes infos chez des gens qui pratiquent. J’ai sollicité antistress qui m’a fait une longue réponse très précise pour le pinning et le sources.list, j’ai échangé avec Seb sur Debian et enfin j’ai piqué l’excellent conseil de Olivyeahh choix p (pinning) lorsque apt-listbugs remonte un paquet bugué. On s’évite ainsi la version foireuse du paquet et la version suivante (probablement corrigée du bug pénible) sera proposée.
L’entraide et le partage sont toujours bien présents dans les communautés du Libre, merci à eux.
Les réseaux sociaux ont pour principe de faire des messages presque éphèmères, qui sont perdus au milieu de tas d'autres. Parmi tous ces messages, j'ai vu celui-ci par Framasky Vous utilisez #BorgBackup et vous souhaiteriez vous assurer que vos serveurs ont des backups récents ? Rien de plus simple avec https://framagit.org/framasoft/borgbackup/borg-dashboard-exporter qui vous avertira par mail si un serveur a des backups trop anciens ???? Et parce que c'est toujours sympa d'avoir un dashboard sous la main, l'exporter crée un fichier JSON utilisable avec https://framasoft.frama.io/borgbackup/borg-dashboard-vue/ , qui vous donne un truc comme ça : https://framasoft.frama.io/borgbackup/borg-dashboard-vue/ #Borg
Je suis allé regardé les deux liens en questions et je vous mets ici une description rapide. Ca peut toujours servir de savoir que des outils comme ceux-là existent.
Borg-dashboard-exporter lit les sorties JSON du listing des sauvegardes fait par borg, vérifie que les dernières sauvegardes ne sont pas antérieures à X jours et crée un fichier JSON adapté au tableau de bord borg-dashboard-vue.
Il peut également envoyer des e-mails pour vous alerter si les sauvegardes sont trop anciennes.
Borg-dashboard-vue quand à lui est donc l'outil graphique qui permet d'afficher en couleur le résultat de l'exploitation du fichier généré par borg-dashboard-exporter.
Un exemple de ce que cela donne :
Borg et Json - Export au format Json
Ces deux outils repose sur le fait que Borg peut lister les sauvegardes dans le format JSON.
borg list --json REPOSITORY
Le traitement de cet export pourra alors être fait d'une autre façon, si besoin.
Pour la 10ème semaine de l'année 2020, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !
De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !
Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !
Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker :)
Le 5 mars la fondation Raspberry Pi a annoncé la sortie d’un nouvel outil officiel, nommé Raspberry Pi Imager, destiné à simplifier l’installation des systèmes d’exploitation sur la carte SD du raspberry pi.
Que vaut ce nouvel outil, quelles améliorations par rapport à l’existant, est-il vraiment utile ? Nous allons voir ça !
Comment flasher une carte SD avec Raspberry Pi Imager ?
Une solution simple et adaptée à tous les OS, mais pas vraiment une nouveauté.
Il existe de nombreuses façons de créer des cartes SD et nous avons nous même écrit plusieurs articles sur le sujet, pour windows ou linux.
En effet, il a longtemps fallu un moyen différent pour chaque système d’exploitation pour flasher une carte. Cependant, cela fait quelques temps déjà qu’un outil compatible avec tous les OS avait vu le jour : Balena Etcher, un outil graphique de création d’image qui, comme Raspberry Pi Imager, est disponible pour Windows, Mac et Linux.
De fait il semble y avoir assez peu de différences entre Etcher et le nouveau Raspberry Pi Imager : compatibilité inter-os ; interface graphique simple ; copie en 3 étapes. Nous sommes sur une équivalence presque complète. Mais alors, y-a-t-il vraiment des différences ?
En haut Balena Etcher, en bas Raspberry Pi Image. Niveau interface nous pouvons parler d’une certaine ressemblance…
Quelques options supplémentaires, principalement un téléchargement automatique.
Si Balena Etcher et Raspberry Pi Imager sont donc très similaires, Raspberry Pi Imager se veut plus spécialisé et offre quelques fonctions supplémentaires.
Première amélioration, Raspberry Pi Imager peut se charger de gérer le téléchargement de l’image à votre place, ce que ne permet pas Etcher. Une façon de simplifier la vie des débutants et d’assurer que la version installée est toujours la plus à jour.
Pour permettre ce téléchargement automatique, Raspberry Pi Imager va aller, au lancement, chercher un fichier .json sur le site de la fondation. Le fichier contient les liens vers les dernières versions des différentes images.
La liste des systèmes téléchargeable directement depuis le site de la fondation.
Il reste bien entendu possible d’utiliser une image personnalisée, à la place, en sélectionnant l’option "Use custom" plutôt qu’une image proposée.
Autres améliorations plus anecdotiques, la présence d’une option "Erase" permettant de formater la carte SD en FAT 32, ainsi que celle d’une option "Misc utility images" permettant de corriger une corruption de la mémoire EPROOM sur un Raspberry Pi 4. Des options utiles, certes, mais qui pouvaient déjà se faire en quelques clics droits et autres copies de fichier. Appelons ça du sucre interfacique…
Mais alors, avions-nous besoin d’un tel outil ?
Cet outil était-il vraiment nécessaire ? Pas sur le plan technique, mais peut-être ailleurs…
Bilan donc, quelques évolutions sympas mais qui n’apportent pas grand chose à une problématique technique qui était déjà réglée depuis longtemps. Et pourtant, est-ce à dire que l’ensemble n’a pas d’intérêt ? C’est loin d’être certain !
Si l’outil apporte finalement assez peu sur le plan technique, il apporte en revanche ailleurs.
En effet, si Balena Etcher proposait déjà un outil avec presque les mêmes fonctionnalités, son statut de projet externe à la fondation pouvait poser quelques problèmes.
Moins connu, car pas directement rattaché à la fondation, Etcher n’est jamais totalement devenu un standard au sein de la communauté, ce qui fait que de nombreuses techniques différentes sont encore employées aujourd’hui, difficile pour les débutants de s’y retrouver.
Non contrôlé par la fondation, l’outil pouvait être amené à évoluer d’une façon incompatible avec les besoins de de celle-ci Difficile dans ce cadre de le recommander comme outil par défaut aux acheteurs/utilisateurs débutants du Raspberry.
À noter tout de même que Etcher est un logiciel libre, comme Raspberry Pi Imager, rien n’aurait donc empêché la fondation de maintenir sa propre version du logiciel plutôt que de construire le sien. Probablement ont-ils jugé plus simple et moins contraignant de faire ainsi.
Les vrais enjeux : simplicité et standardisation.
Au final, si ce nouvel outil apporte donc assez peu sur le plan technique, il devrait permettre à la fondation de créer une sorte de méthode standardisée et commune aux différents systèmes d’exploitation pour installer la carte SD du Raspberry. Une méthode qu’ils pourront par exemple inclure dans la notice d’utilisation du Pi, dans leurs tutoriels, vidéos, etc.
L’étape de création de la carte SD étant la première dans l’utilisation du Raspberry Pi, sa prise en main va donc s’en trouver largement standardisée et simplifiée, ce qui est exactement ce dont la fondation, mais aussi la communauté, avait besoin !
