Aujourd’hui nous allons faire tomber un mythe : la commande git rebase. Non, elle n’est pas compliquée, c’est juste que vous y avez souvent été confrontée dans une situation de stress sans trop comprendre ce qui se passait, par exemple dans un git pull –rebase qui se passe mal. Nous allons étudier un cas simple et vous allez désormais l’utiliser quasiment au quotidien. Oui oui, au quotidien.

Fusion ? Git rebase ?

Si cette partie relativement théorique ne vous intéresse pas, sautez directement au chapitre suivant pour l’exemple pratique.

En prérequis nous allons faire un rappel rapide de ces deux notions. La fusion consiste à prendre les différents commits, à en étudier la possibilité des les assembler et à générer un nouveau commit. D’où le terme de fusion. Vos deux branches d’origine restent inchangées, modulo le nouveau commit créé.

Le rebase fonctionne différemment. Lorsque vous voulez effectuer un rebase, Git va rechercher le commit commun le plus récent entre les deux branches, puis va essayer de constituer une branche cohérente résultante de cette opération.

La grosse différence donc est que dans le cas de la fusion, on obtient le résultat dans un nouveau commit , alors que rebase va retravailler la branche sur laquelle vous êtes.

Cette explication est bien sûr clairement vulgarisée, imparfaite et sommaire, et je vous invite à lire la documentation officielle si vous souhaitez plus de détails.

Entrons dans le vif du sujet avec un cas d’usage que vous rencontrez tous les jours. Croyez-moi.

Le commit imparfait

Cas typique d’usage de rebase : la correction d’un commit imparfait. Vous êtes allé trop vite et avez oublié d’embarquer un fichier dans votre commit, alors vous faites un nouveau commit pour corriger, avec le plus souvent un message peu clair car vous êtes énervé. Ne niez pas, ça nous est tous arrivé et ça vous arrive peut-être encore souvent.

C’est parfait, on va corriger ça avec rebase.

Commençons par mettre l’environnement de test en place avec un nouveau dépôt Git. On passe rapidement sur ces opérations car on en a déjà parlé dans cet article .

$ git init .Initialized empty Git repository in /home/user/debuter-avec-git/7/.git/$ echo "foofoofoo" > file1$ git add file1 $ git commit file1 -m "initial commit"[master (root-commit) 9a8a61f] initial commit 1 file changed, 1 insertion(+) create mode 100644 file1

On initie un nouveau dépôt, puis un créé un premier commit avec un fichier file1 .

$ echo "barbarbar" > file2$ git add file2$ git commit file2 -m "add file2"[master dcd1b75] add file2 1 file changed, 1 insertion(+) create mode 100644 file2

On ajoute ensuite un deuxième commit, contenant un fichier file2 .

La double boulette

Nous voulons maintenant ajouter deux fichiers en même temps au dépôt. Malheureusement pour vous, une réunion commence, vous êtes en télétravail et vous continuez à travailler pendant que votre chef soliloque dans votre casque (on en parle dans cet article ). Et là…

$ echo "blablabla" > file3$ echo "lalalala" > file4$ git add file3$ git commit file3 -m "add file3 and file4"[master 122fa7d] add file3 and file4 1 file changed, 1 insertion(+) create mode 100644 file3

La boulette ! Vous avez oublié d’ajouter le fichier file4 ! Tout ça à cause de la réunion !

$ git statusOn branch masterUntracked files:  (use "git add ..." to include in what will be committed)	file4

Vous tentez de corriger.

$ git add file4$ git commit file4 -m "azlemjrlmzjaejrlj"[master 23486d2] azlemjrlmzjaejrlj 1 file changed, 1 insertion(+) create mode 100644 file4

Vous venez en fait d’aggraver la situation. Vous ajoutez à votre première erreur la lourdeur d’un nouveau commit sans réel intérêt et, de plus, un message de commit inutile, sans valeur pour vous et vos collègues. En effet jetons un œil à votre historique avec la commande git log .

$ git logcommit 23486d2a4052710025ea76b6a79ae4a481bef8af (HEAD -> master)Author: Carl Chenet Date:   Tue Mar 2 13:17:59 2021 +0100    azlemjrlmzjaejrljcommit 122fa7da505bfd924482dbeb393b1bd64796c874Author: Carl Chenet Date:   Tue Mar 2 13:17:12 2021 +0100    add file3 and file4commit dcd1b7500c56025b43172d05d2e071d38544d8e5Author: Carl Chenet Date:   Tue Mar 2 13:15:30 2021 +0100    add file2commit 9a8a61f662ea8397f03fdf1b19d45a053dbb83d7Author: Carl Chenet Date:   Tue Mar 2 13:14:33 2021 +0100    initial commit

On le voit, le dernier commit est, disons-le, laid, sans valeur ajoutée pour personne. Il fait le travail certes mais doit être amélioré, surtout dans le cadre du travail collaboratif où vous n’êtes pas le seul à lire cet historique (voir plus bas). Vous allez faire perdre du temps à tous vos relecteurs.

Git rebase à la rescousse

Nous allons maintenant voir l’intérêt de rebase. Vous passez la commande suivante pour “retravailler” les deux derniers commits.

$ git rebase -i HEAD~2

Cette commande signifie que nous souhaitons appliquer la fonction rebase à partir de HEAD , notre position actuelle sur la branche courante (on en a parlé dans cet article ) jusqu’au deuxième commit en arrière.

Un menu apparaît dans votre éditeur qui va vous demander des informations.

pick 122fa7d add file3 and file4pick 23486d2 azlemjrlmzjaejrlj# Rebase dcd1b75..23486d2 onto dcd1b75 (2 commands)## Commands:# p, pick  = use commit# r, reword  = use commit, but edit the commit message# e, edit  = use commit, but stop for amending# s, squash  = use commit, but meld into previous commit# f, fixup  = like "squash", but discard this commit's log message# x, exec  = run command (the rest of the line) using shell# b, break = stop here (continue rebase later with 'git rebase --continue')# d, drop  = remove commit# l, label  = label current HEAD with a name# t, reset  = reset HEAD to a label# m, merge [-C  | -c ]  [# ]# Note that empty commits are commented out

Le haut de ce menu présente une liste des commits qui vont être retravaillés par rebase, les commits sont affichés selon leur ancienneté, de haut en bas (attention, contrairement à git log donc). Tout le reste du fichier est constitué de commentaires à caractère informatif.

Le premier mot précise quelle modification appliquer. Nous allons utiliser le mot-clé fixup pour fusionner le commit désigné avec le précédent, le message de commit du précédent sera également conservé et celui du commit designé sera supprimé. D’une pierre deux coups, donc.

pick 122fa7d add file3 and file4fixup 23486d2 azlemjrlmzjaejrlj

Nous sauvons maintenant le contenu du fichier.

$ git rebase -i HEAD~2Successfully rebased and updated refs/heads/master.

Le message annonce que l’opération rebase a été correctement effectuée. Un coup d’œil sur notre historique va nous le confirmer.

$ git logcommit 4fb9e75b8749453936d7cfa409127e228aefdc60 (HEAD -> master)Author: Carl Chenet Date:   Tue Mar 2 13:17:12 2021 +0100    add file3 and file4commit dcd1b7500c56025b43172d05d2e071d38544d8e5Author: Carl Chenet Date:   Tue Mar 2 13:15:30 2021 +0100    add file2commit 9a8a61f662ea8397f03fdf1b19d45a053dbb83d7Author: Carl Chenet Date:   Tue Mar 2 13:14:33 2021 +0100    initial commit

Nos deux erreurs ont bien été corrigées. Nous présentons maintenant un commit cohérent, avec un message de commit explicite. Une étude du commit nous le confirme.

$ git show --pretty=oneline 4fb9e75b8749453936d7cfa409127e228aefdc604fb9e75b8749453936d7cfa409127e228aefdc60 (HEAD -> master) add file3 and file4diff --git a/file3 b/file3new file mode 100644index 0000000..6a4238f--- /dev/null+++ b/file3@@ -0,0 +1 @@+blablabladiff --git a/file4 b/file4new file mode 100644index 0000000..854f93c--- /dev/null+++ b/file4@@ -0,0 +1 @@+lalalala

Les deux fichiers sont bien ajoutés par ce commit désormais unique.

L’utilisation de git rebase dans le cadre du travail collaboratif

Comme nous avons vu, nous aurions pu conserver cette historique et continuer à travailler, mais le problème survient lorsqu’un collègue va vouloir relire l’historique. Si nous n’avions pas corrigé, votre collègue aurait lu azlemjrlmzjaejrlj comme message de commit et aurait donc dû lire lui-même le détail du commit, une opération que l’on peut donc facilement éviter avec un message de commit explicite.

Voyons maintenant comment corriger l’erreur au niveau du dépôt partagé avec les collègues. Nous avions poussé notre double erreur vers le dépôt Gitlab.

$ git push origin masterEnumerating objects: 4, done.Counting objects: 100% (4/4), done.Delta compression using up to 8 threadsCompressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 273 bytes | 273.00 KiB/s, done.Total 3 (delta 1), reused 0 (delta 0)To https://gitlab.com/articles/debuter-git-7.git   9b95c2c..95fe5b2  master -> master

Après notre utilisation du rebase, nous retentons de pousser notre modification.

$ git push origin masterTo https://gitlab.com/articles/debuter-git-7.git ! [rejected]        master -> master (non-fast-forward)error: failed to push some refs to 'https://gitlab.com/chaica/debuter-git-7.git'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Integrate the remote changes (e.g.hint: 'git pull ...') before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Une erreur apparaît. Git nous informe qu’il ne peut pas effectuer l’opération fast-forward, assurant la bonne conduite de la mise-à-jour distante. Il va falloir effectuer une opération un peu plus complexe avec l’option –force-with-lease .

$ git push --force-with-lease origin masterEnumerating objects: 5, done.Counting objects: 100% (5/5), done.Delta compression using up to 8 threadsCompressing objects: 100% (2/2), done.Writing objects: 100% (4/4), 341 bytes | 341.00 KiB/s, done.Total 4 (delta 0), reused 0 (delta 0)To https://gitlab.com/chaica/debuter-git-7.git + 95fe5b2...831f45c master -> master (forced update)

Attention. Je ne détaille pas cette option ici mais pour information N’UTILISEZ JAMAIS L’OPTION –force sans être absolument 100% sûr de ce que vous faites et/ou avant d’avoir consulté vos collègues. C’est très souvent une très mauvaise idée. Et presque 100% du temps une bêtise si vous travaillez sur la branche master en collaboration avec d’autres personnes. À éviter donc.

L’option –force-with-lease , contrairement à l’option – -force , va vérifier que le pointeur distant est encore bien positionné sur votre dernier commit précédant le rebase et que tous les pointeurs distants utilisent bien ce commit et donc que quelqu’un d’autre n’a pas retravaillé votre historique, auquel cas vous écraseriez son travail avec –force .

En gros, retenez que vous êtes sûr à 100% de n’impacter personne d’autre avec l’option –force-with-lease de git push quand vous souhaitez pousser votre historique modifié.

Maintenant le retravail de votre historique a bien été poussé sur le dépôt distant, votre commit est bien plus lisible et votre message de commit explicite, prêt à être relu par un collègue.

Le retravail des messages de commits

Il s’agissait ici d’un exemple très simple pour vous initier à la puissance de rebase. Nous n’avons travaillé que sur 2 commits. Vous pourriez en embarquer bien davantage dans votre opération. Vous pouvez même envisager des opérations concernant l’intégralité des commits sur une branche. Boowaa!

Une autre utilisation très classique est le retravail des messages de commits. Nous avons vu – lorsque que rebase vous demande quelle(s) opération(s) vous souhaitez effectuer – que nous avions à notre disposition l’option suivante :

# r, reword  = use commit, but edit the commit message

Vous pouvez donc revenir sur un ou plusieurs messages de commits voire même tous les messages de commits de votre branche, par exemple pour y appliquer un formalisme nécessaire à votre gestionnaire de tickets ou à votre CI/CD. Vous ne pourrez bientôt plus vous en passer, les petites typos que vous avez laissées partout traîner dans vos messages parce que vous ne saviez pas comment les corriger ? Rebase commence à vous plaire, je le sens.

La puissance de git rebase

Notons que nous avons utilisé l’option fixup pour fusionner deux commits pendant l’opération et supprimer le message de celui sur lequel on avait déclaré vouloir effectuer le fixup .

Si vous aviez voulu conserver les deux messages de commits pour les retravailler, vous auriez pu utiliser l’option squash , très couramment utilisée également dans les opérations de rebase.

# s, squash  = use commit, but meld into previous commit

D’autres options plus avancées comme edit ou exec permettent des opérations puissantes et complexes, mais on sort un peu du cadre de l’article. À découvrir donc le jour où vous en aurez besoin

Ceinture et bretelles

N’oubliez jamais que mieux vaut prévenir que guérir.

Avant de tenter une manipulation qui vous semble complexe, n’hésitez pas à copier l’intégralité du répertoire racine qui contient vos sources (celui qui contient le répertoire .git ) vers un autre endroit avant d’effectuer votre opération. C’est moche et ça fait rigoler les puristes certes (je vous vois rigoler là au fond) mais ça peut vous éviter bien des ennuis si vous êtes coincé et que personne n’est là pour vous aider. Il faut bien s’entraîner avant de maîtriser, c’est vrai pour tous les outils. Avec une sauvegarde à côté, on ne pourra jamais vous reprocher d’avoir perdu des données.

De plus, bien souvent dans les opérations de rebase qui tournent mal, un simple git rebase –abort vous permet de revenir à l’état antérieur à l’opération.

Conclusion

Nous allons nous arrêter ici pour l’article d’aujourd’hui. Nous avons montré un cas d’utilisation très commun de rebase et comment pousser un historique modifié par rapport à celui qui avait déjà été poussé vers un dépôt partagé.

Je vous encourage à tester rapidement le retravail des messages de commits, c’est également une option dont je me sers assez souvent. Nul doute qu’en maîtrisant ces bases, vous aborderez sereinement les cas d’utilisations plus complexes si un jour vous y êtes confronté.

Finalement et pour rappel, le rebase est une opération puissante et donc comme beaucoup de choses dans Git potentiellement dangereuse, n’hésitez pas à faire une sauvegarde de vos données avant de vous lancer.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre :

• Mastodon : @carlchenet
• Diaspora : @carlchenet
• Twitter : @carl_chenet

Suivre l’actualité du Logiciel Libre et Open Source francophone

Abonnez-vous au Courrier du hacker , une newsletter hebdomadaire résumant le meilleur de l’actualité francophone du Logiciel Libre et Open Source. Déjà plus de 160 numéros et 3500 abonnés.

[yikes-mailchimp form="1" submit="S'abonner"]

The post Débuter avec Git partie 7 : git rebase pour ré-écrire son historique appeared first on Carl Chenet's Blog .

Original post of Carl Chenet .Votez pour ce billet sur Planet Libre .

J'avais migré en Janvier 2013 mon blog vers Pelican en venant de Dotclear . Pelican est un générateur de site statique en Python. J'avaisalors dû faire l'impasse sur les commentaires mais au bénéfice d'un site performant et avec unesurface d'attaque plus faible.

Plus tard, en décembre 2016, j'avais changé le thème pour alexandrevicenzi/Flex .Aujoud'hui je vais vous montrer la migration de mon blog vers Gridsome .

Je reste sur un générateur de site statique car, j'aime l'idée d'un site à la fois rapide etimmuable tant que je ne décide pas de modifier le contenu mon blog. Alors pourquoi changer de Pelicanvers Gridsome ?

Gridsome est un générateur de site statique écrit en Javascript. Il a la particularité de pouvoir générerdes pages depuis des fichiers au format Markdown mais aussi depuis des CMS Headless, ou de n'importequelles autres API et ce grace à une API commune en GraphQL.

En plus de générer le site statique au format HTML, Gridsome fonctionne comme une SPA ¹ . Dans une SPAles pages sont générées côté client et sont mises à jour lors d'appel API pour récupérer les données. Ainsiseul le contenu modifié est rafraichit. Le framework Gridsome se base sur Vue.Js .

Ce qui m'a plus dans Gridsome, c'est l'utilisation de Vue.JS pour générer les pages statiques, mais aussil'utilisation de GraphQL pour requêter le contenu des pages d'une même et unique façon.

Alternatives

Lors de la migration de mon blog, je voulais une technologie basée sur Vue.Js, car c'est un framework quej'apprécie. Mais le plus important, c'est que j'avais besoin de changement (pour le plaisir quoi ;)).

Les générateurs de site statique en Vue.Js sont :

• VuePress
• Nuxt.js
• Saber
• Gridsome

Je vous laisse regarder et vous faire votre avis sur les différents framework. J'ai surtout testé VuePress maisj'ai changé pour Gridsome quand j'ai vu la simplicité d'implémentation.

Début de l'implémentation

Je voulais changer de technologie, mais j'aimais bien le thème Pelican que j'utilisais. Je n'avais donc pasenvie de le changer. Je me suis imposé également les contraintes suivantes:

• Je ne voulais pas changer les différents chemins d'accès au site (tant que faire se peut).

• Je voulais garder les fonctionnalités suivantes:

  • Sitemap
  • Atom
• J'avais des billets écrits en Markdown mais aussi 3 pages que je ne voulais pas réécrire en HTML
• Garder le même thème
• Avoir une page par catégorie et une page avec toutes les catégories
• Avoir une page par tag et une page avec tous les tags

Je commence donc à initialiser un projet de zéro avec mes différents billets de blog, les pages (contact,anciens-projets, et contact) et les fichiers statiques (les images, les zips, ...).

J'ai du retravailler les différents billets de blog au format Markdown:

• J'ai dû déplacer les différents attributs du fichier pour les placer dans un frontmatter au format YAML.

• Les fichiers ont un nom qui porte de l'information. Ainsi, le dossier dans lequel se trouve le fichierconstitue le nom de la catégorie, et le nom du fichier porte la date de publication et le slug (utilisépour le chemin dans l'URL).

  Par exemple, avec le fichier: Logiciels/2009-02-15_debian-lenny-est-sortie.md .

  Avec le changement de paradigme de Gridsome, j'ai dû intégrer ces différentes informations dans le frontmatter.

• J'ai également du retravailler les emplacements de fichiers qui étaient préfixés dans Pelicande |static|/public/... . Dans Gridsome, il n'y pas de syntaxe particulière, juste le nom du fichier absolu.

Avant j'avais:

Title: Debian Lenny est sortieTags: debian, kde![Logo](|static|/public/Logiciels/debian-lenny-est-sortie/debian-logo.png)

et j'ai corrigé cela en

---title: Debian Lenny est sortiedate:2009-02-15tags:- debian  - kdepublished:Truecategory: Logiciels---![Logo](/Logiciels/debian-lenny-est-sortie/debian-logo.png)

Afin de pouvoir reprendre mes fichiers au format markdown sans trop de modification, j'ai également installé lesplugins remark suivants (ce sur quoi Gridsome se base pour transformer le Markdown en HTML) :

• @gridsome/remark-prismjs : pour effectuer une coloration syntaxique.

• remark-inline-links : pour pouvoir gérer les liens inclus (qui sont ensuite reportés en bas du fichier)

  [foo], [foo][], [bar][foo].![foo], ![foo][], ![bar][foo].[foo]: http://example.com "Example Domain"

• remark-attr : pour pouvoir ajouter des attributs à une image ou à un objet.

  ![alt](img){attrs} / ![alt](img){ height=50 }

• remark-toc : pour pouvoir ajouter un sommaire à certain billet.
• remark-footnotes : pour pouvoir ajouter les footnotes.

Création du thème

Le thème Pelican de mon blog est basé sur alexandrevicenzi/Flex .J'ai donc créé un thème gridsome en reprenant le style du thème précédent mais en convertissant les templatesen Vue.Js.

J'ai donc créé ce thème que j'ai mis à disposition ici : phoenix741/gridsome-flex-markdown-starter .

Voici la configuration de gridsome que j'ai implémenté pour reconstruire le thème du blog:

  plugins:[{      use:"@gridsome/source-filesystem",      options:{        baseDir:"content/posts",        path:"**/*.md",        typeName:"Post",        refs:{          tags:{            typeName:"Tag",            create:true,},          category:{            typeName:"Category",            create:true,},},},},

Pour commencer, on utilise le module @gridsome/source-filesystem pour lire le contenu du dossier content/posts/**/*.md . On définit au plugin comment on créé les Tag et les Category .

{      use:"@microflash/gridsome-plugin-feed",      options:{        contentTypes:["Post"],        rss:{          enabled:true,          output:"/feed.xml",},        atom:{          enabled:true,          output:"/feed.atom",},},},

Ensuite on crée un flux RSS et un flux ATOM avec ces posts, afin que les lecteurs qui utilisentencore un lecteur de flux, ou les programmes qui s'abonnent directement à mon site fonctionnent encore.

{      use:"@gridsome/source-filesystem",      options:{        baseDir:"content/pages",        path:"*.md",        typeName:"BlogPage",},},

On recommence avec les pages du site, que l'on type comme BlogPage . Ces pages ne serontpas accessibles via des catégories ou des pages. Il faudra faire des liens directement vers lespages depuis un menu.

{      use:"@gridsome/plugin-sitemap",      options:{        config:{"/post/*":{            changefreq:"weekly",            priority:0.5,},"/page/*":{            changefreq:"monthly",            priority:0.7,},},},},

Après, on définit un sitemap qui pourra être utilisé par les moteurs de recherches.

],  templates:{Post:(obj)=>{return("/post/"+ obj.fileInfo.name.replace(/^\\d{4}-\\d{2}-\\d{2}[_\\-]/,""));},BlogPage:"/pages/:fileInfo__name",Tag:"/tag/:id",Category:"/category/:title",},

On définit les différentes chemins d'accès pour nos billets, nos pages, nos Tag ,et nos Category . Comme je ne souhaite pas changer les adresses de mes billets sur mon site,j'ai défini les adresses sur les mêmes chemins que mon blog sous Pelican.

Comme les noms des fichiers des billets portent la date et le nom du billet, pour retrouverle nom du chemin d'origine, je supprime la date pour la génération du chemin.

  transformers:{    remark:{      plugins:[["@gridsome/remark-prismjs",{ showLineNumbers:true}],"remark-inline-links",["remark-toc",{ heading:"sommaire"}],"remark-attr",],      config:{        footnotes:true,},},},

Enfin, je définis les différents plugins dont j'ai besoin pour que mes différents billetsfonctionnent correctement.

  permalinks:{    trailingSlash:"false",    slugify:{      use:"@sindresorhus/slugify",      options:{        decamelize:false,},},},  css:{    loaderOptions:{      less:{// options here will be passed to less-loader},},},};

Je termine par modifier la manière dont Gridsome transforme les adresses, toujours pourque les chemins de mon blog ne changent pas.

Développement des pages

Viens ensuite l'écriture des différentes pages, composants et layout pour définir notre thème.Le plus compliqué, c'est que le résumé (excerpt) fourni par Gridsome supprime le rendu HTML etles retours chariots.

Je voulais que sur la page principale de mon application, je puisse générer un résumé de chaquebillet avec le texte et le rendu original du billet.

Pour cela malheureusement Gridsome ne fournit pas une manière simple de générer un résumé. Je vaisvous présenter mon implémentation afin d'avoir un résumé au format Markdown.

Ma première version a été de créer à partir de contenu HTML le résumé dans un composant vue dédié.Lors de la génération des pages statiques, le résultat était comme attendu. Par contre lors duchangement des pages (en mode SPA), le billet intégral du blog est chargé, pour être tronqué dynamiquement. Cequi est long et pas performant quand cela arrive sur 10 billets à la suite. J'ai donc modifié le système pourgénérer les pages côté serveur.

Pour cela j'ai donc modifié le fichier gridsome.server.js . Le problème, c'est que Gridsome ne permetpas d'appeler un transformer (remark) directement, et ne permet pas de convertir un text en markdown (autrementqu'en passant par le plugin @gridsome/source-filesystem ).

J'ai donc dû implémenter l'appel à remark (et les différents plugins) directement dans la partieserveur manuellement.

Une fois le fichier HTML obtenu, j'appelle une librairie dédiée truncatise afin de réduire le contenuà quelques paragraphes (4).

const truncatise =require("truncatise");const remark =require("remark");const html =require("remark-html");const remarkPrism =require("@gridsome/remark-prismjs");const remarkInlineLinks =require("remark-inline-links");const remarkToc =require("remark-toc");const remarkAttr =require("remark-attr");const remarkFN =require("remark-footnotes");module.exports=function(api){  api.loadSource(({ addSchemaResolvers })=>{addSchemaResolvers({Post:{        excerpt:{          type:"String",asyncresolve(obj){returnnewPromise((resolve, reject)=>{remark()// Appel des différents plugins utilisé coté config..use(remarkPrism).use(remarkInlineLinks).use(remarkToc,{ heading:"sommaire"}).use(remarkAttr).use(remarkFN)// Génération HTML.use(html).process(obj.content,function(err, file){if(err){returnreject(err);}// On tronque en ne gardant que les 4 premiers paragraphesresolve(truncatise(String(file),{TruncateLength:4,TruncateBy:"paragraphs",Strict:false,StripHTML:false,Suffix:" ...",}));});});},},},});});};

C'est ainsi que j'ai converti mon blog vers le framework Gridsome . Je vous passe tous lesdétails (vu que le thème est disponible sur Github sur phoenix741/gridsome-flex-markdown-starter ).

Ajout d'un système de commentaire

Ce qu'il manquait sur mon blog précédent c'était un système de commentaires. J'ai donc ajoutéce système de commentaires à mon blog.

Je ne souhaitais pas ajouter n'importe quel système de commentaires. J'ai donc regardéce que je pouvais ajouter sur un site statique. On va retrouver les systèmes de commentairesnon libres, et faciles à implémenter (et pas forcément très compatible RGPD).

• Disqus
• Facebook comments
• ...

De mon coté je me suis dirigé vers les systèmes de commentaires libres:

• Vssue
• Gitment
• Utterances
• Remark42

Remark42 nécessite l'installation d'un programme sur mon serveur. Je l'ai testé mais j'ai été à quelquesproblème lors de l'intégration avec Gridsome.

Vssue, Gitment et Utterances sont intéressants car ils permettent d'ajouter un système de commentairesse basant sur le système de ticketing de Github. Github n'est en lui même pas OpenSource mais les frameworksci-dessus le sont.

Je considère que la plupart des personnes lisant mon blog ont un compte Github. Mais n'hésitez pas à commentersi ce n'est pas le cas ;).

Vssue était mon système préféré, beau, simple compatible avec Gitea (que j'utilise pour mes sources), Gitlab,et avec Github également. Mais dû aux limitations de Github et Gitea, il m'était nécessaire de fournir mon ClientSecret OAuth2 .

Je n'ai pas apprécié cette idée mais j'ai tout de même voulu tester. Là je me suis rendu compte qu'ily avait des problèmes CORS. Le composant passe par CORS Anywhere maisce dernier ne peut être utilisé que pour le développement. Ce qui signifie que je dois installer un proxy équivalentsur mon serveur. J'ai donc regardé pour autre chose.

J'ai alors testé Utterances. Le problème est que cette librairie n'est pas compatible avec lesapplications de type SPA. On peut voir d'ailleurs quelques commentaires sur le ticket Github #231 de personnes ayant tenté de faire une version du client pour Vue.Js.

Je me suis donc inspiré d'un composant Vue.JS écrit par quelqu'un d'autre (dans le 1er commentaire) pour inclurece système sur mon site.Ce composant a dû être légèrement adapté pour fonctionner (je vous invite à regarder GithubComponent.vue ).

Comme le plugin utilise directement l'objet window, il ne peut fonctionner avec le mode SSR (Server Side Rendering) deVue.Js. J'ai dû donc désactiver le mode commentaires pour le côté SSR (la génération). Ce n'est pas déconnant carde toutes façon les commentaires sont gérés sur Github.

Voici comment on fait avec Gridsome. On commence par encadrer le bloc qui ne doit pas faire partie de la générationcôté serveur (et qui est donc Client Only ). Ce bloc contient notre composant GithubComponent .

<article>  ...  <ClientOnly><divclass="commentswrap"><divid="comments"><GithubComponent:title="$page.post.title":repo="$page.metadata.utterances.repo":pathname="this.$route.path":url="url":issueTerm="$page.metadata.utterances.issueTerm":label="$page.metadata.utterances.label">GithubComponent>div>div>ClientOnly>article>

Enfin on charge le composant dynamiquement dans la partie Javascript.

exportdefault{  components:{PostHeaderTitle,GithubComponent:()=>import("../components/GithubComponent").then((m)=> m.default).catch(),},...}

Ces deux opérations permettent d'exclure cette partie lors de la génération des pages statique, mais del'ajouter dynamiquement après le chargement de la page coté client.

Conclusion

Voici donc comment j'ai mis en place la version Vue.JS de mon blog. N'hésitez pas à m'envoyer un mailou lâcher un commentaire.

Vous pouvez retrouver le kit de démarrage que j'ai fait pour mon blog sur github: phoenix741/gridsome-flex-markdown-starter . Vous pouvez également consulter l'intégration d'utterances sur un siteen vue ici: phoenix741/gridsome-flex-markdown-starter:GithubComponent.vue .

Original post of Ulrich Van Den Hekke .Votez pour ce billet sur Planet Libre .

Pour la 8ème semaine de l'année 2021, voici 12 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 !

• Une infra en Data Center ?
• Le logiciel libre dans l'environnement de la Gendarmerie nationale
• Bienvenue sur Libreon !
• Le télétravail, c'est pas que pour la pandémie !
• Êtes-vous sûrs de vos bonnes pratiques ?
• Scraper des paroles de chansons avec requests et Beautiful Soup
• Installer son serveur XMPP avec Prosody
• [OpenBSD :: Virtualisation] Hôte et invité(s) sont sur le même bateau
• FreeBSD + Ntopng : Transformez votre Raspberry Pi en IDS
• Le Wiki d'Herminien, l'informatique expliqué à tes potes
• Consommer "Local-First" en informatique
• Mon point de vue détaillé sur l’auto-hébergement

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

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 :)

Original post of Journal du hacker .Votez pour ce billet sur Planet Libre .

Tout d'abord il me faut indiquer quels usages je fais de mon téléphone.

J'utilise surtout les fonctions SMS et MMS , appareil photo et voix – dans cet ordre, de sorte que mes critères sont en général la qualité de l'appareil photo, l'autonomie, une taille raisonnable (un point qui devient difficile à satisfaire), et bien sûr la prise en charge d'un système d'exploitation libre (comme LineageOS par exemple). Mon forfait est à l'avenant puisque je recours au forfait 2€ de Free permettant 2 heures de communication, SMS/MMS illimités et un opulent forfait Internet 50 Mo . Mon usage, généralement dépourvu d'internet comme vous l'aurez compris, me permet plusieurs jours d'autonomie (généralement une semaine – contre deux pour le NOKIA 6020 qui précédait mon basculement, il y a cinq ans, dans le monde des smartphones ).

Ce Samsung S5 est mon quatrième smartphone , un peu malgré moi d'ailleurs (j'y reviendrai).

Après un ZTE OpenC sous Firefox OS (acquis neuf en janvier 2016, 30€), les suivants ont tous roulé LineageOS : Sony Xperia Z5 Compact (acquis neuf en octobre 2018, 140€), Samsung Galaxy A3 2017 (acquis neuf en juillet 2019, 170€) et le petit dernier (acquis neuf en décembre 2020, 89€) : un Samsung Galaxy S5 (oui, oui, un modèle lancé en 2014).
C'est une chute de trop (malgré leur étui de protection) qui m'a poussé à remplacer successivement les Xperia Z5 Compact (plus de mise au point de l'appareil photo) et Galaxy A3 2017 (hémorragie de cristaux liquides inondant l'écran). Pour des objets du quotidien, ces appareils sont très peu solides.

Je dirais simplement que je suis très content de ce modèle à l'appareil photo de qualité, à la batterie amovible, extensible par carte SD jusqu'à 128 Go, qui reçoit des mises-à-jour hebdomadaires et qui m'a été conseillé sur LinuxFr comme sur le forum de HFR (merci à vous !).

Pour installer LineageOS, les seuls conseils que je donnerais sont :

• Pour ce qui est du logiciel Heimdall , j'ai eu recours au paquet heimdall-flash de ma Debian qui marche sans souci ;
• Le flashage fonctionne sans carte SIM (le temps de récupérer une micro SIM) ;
• Le câble Samsung fonctionne bien pour charger l'appareil mais visiblement pas pour transférer des données : j'ai dû utiliser un autre câble, celui de ma lampe de vélo ;-)

Si je dois citer trois petits bémols :

• En mode téléphone l'écran s'éteint, notamment quand j'appelle mon répondeur : pas pratique pour appuyer sur le clavier pour effectuer les commandes. Ou quand je décroche. Si j'approche le tél de mon oreille et l'éloigne, l'écran va se rallumer puis se réteindre. Faudra que je note précisément les cas d'usage car ce n'est pas tout le temps. Quelqu'un a t-il ce problème ?
• Si l'on veut sauvegarder directement les photos sur la carte SD, les logiciels ne le gèrent pas très bien. Finalement j'ai décidé de les enregistrer sur le téléphone lui-même, quitte à les transférer d'un bloc quand je manquerai de place (bug connu, voir la page dédiée à cette ROM ).
• Le format du téléphone est un peu grand par rapport à ce que j'avais avant, mais bon (surtout avec l'étui géant façon playschool que je lui ai adjoint ).

Au final j'apprécie la qualité des photos en extérieur, l'endurance très correcte de la batterie, la réactivité du système et de Fennec F-Droid (alias Firefox Mobile), les mises à jour… J'espère qu'il durera !

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

L’équipe elementary, au travers de Cassidy James a réalisé un live Youtube ce jour sur les fonctionnalités à venir sur la nouvelle release à venir d’elementary « Odin »

Durant ce live, Cassidy a pu aborder les sujets suivants :

• Une version d’Odin disponible sur Raspberry Pi, il est donc possible de se dire que le support des processeurs ARM pourrait être possible.
• Le support officiel du thème sombre.
• Le programme d’accès anticipé aux ISO de développement d’Odin (sous réserve de supporter l’équipe au travers de Github Sponsor ou via la campagne Indiegogo « AppCenter for Everyone »).
• Une session live de développement sur Dippi.
• L’ouverture de l’AppCenter a d’autres distributions Linux via « AppCenter for Everyone » au travers de Flatpak.
• Réinstallation ou upgrade depuis une version d’elementary ? L’équipe préfère la direction d’une réinstallation, toutefois, la décision n’est pas (encore) arrêtée sur la mise à jour vers Odin depuis une version précédente (Hera).
• Cassidy a aussi confirmé pendant ce live que Mail 2.0 a été totalement ré-écrit.
• Le support de l’API Cloudproviders dans Fichiers est validée.
• Online account nécessite encore du travail.
• Une démo de Multi Touch (TouchEgg) a été réalisée (et c’est impressionnant à voir).
• Odin permettra de mettre à jour certains micrologiciels.

Le billet Live QA avec Cassidy James Blaede a été publié sur le site de la elementary OS -

Original post of elementary OS .Votez pour ce billet sur Planet Libre .

Ton chef rage en mode “c’était mieux avant”, tu le vois continuer à organiser des réunions-fleuve où personne ne répond. Le reste du temps (et pendant ses réunions) ton équipe et toi abattez le boulot, comme avant alors que tout le monde est en télétravail. C’est indiscutable, la boîte n’a pas coulé. On va parler de pourquoi le télétravail va rester après la pandémie et ce que ta boîte peut en retirer. Et toi aussi.

Un constat dans l’entreprise : rien n’a dramatiquement changé

Cela fera bientôt un an qu’on est plus ou moins à distance dans les entreprises. La boîte tourne, l’argent rentre (peut-être un peu moins bien, mais c’est davantage lié à la conjoncture), l’infrastructure de l’IT a tenu le choc. Alors on parle de quoi ?

Quand t’entends parler ton chef, tu sens un léger décalage entre sa perception du télétravail et la tienne. J’en ai parlé dans cet article , le choc culturel est dur. Lui n’arrête pas de se plaindre en mode “la machine à café me manque tellement” ou le classique “on ne peut plus socialiser” alors que tu ne le voyais jamais en dehors des réunions qu’il organisait. Faut se l’avouer au bout d’un moment : dans les faits au niveau du travail, rien n’a changé, ou si peu.

De toute façon que tu sois au bureau ou chez toi, quand à sa réunion hebdo ton chef blablatait pendant deux heures, tu faisais autre chose, tu bossais le plus souvent, puis vu qu’il t’empêchait de te concentrer tu finissais par aller sur LinkedIn/FB/Twitter/Tiktok (jamais au bureau, ouais ouais), donc quelle différence ? À part la fausse impression qu’il pouvait contrôler mieux ses troupes parce qu’il les avait sous les yeux, aucune.

D’ailleurs précisons un point : ton chef parle tout le temps de socialiser mais bizarrement tu le vois jamais sur la messagerie instantanée de l’entreprise Slack/Teams/ Rocket.chat , sauf quand il faut gueuler car le service est arrêté (mais tout le monde est déjà au courant). Classique.

Ce que l’entreprise peut gagner avec le télétravail après la pandémie

La pandémie a été un plongeon forcé vers le télétravail pour les entreprises. On peut le regretter, mais la vérité c’est que seuls ces types d’événements ou les contraintes légales sont à mêmes de transformer à ce point et si rapidement ces organisations.

Pour ceux qui n’auraient pas compris : une entreprise, c’est un ensemble historique de procédures et de façons de faire un ou plusieurs métiers qui génèrent de l’argent. L’entreprise, donc, ça n’aime pas le changement. Et surtout pas les changements brusques.

Donc toutes celles qui pouvaient et avaient vraiment besoin de leur troupe ont mis en place le télétravail. Elles ont donc assuré la continuité de leur activité en imposant davantage leur présence dans l’espace jusqu’ici personnel de leurs salariés : le domicile.

L’accès continu aux employés par le télétravail pendant la pandémie

Alors qu’avant beaucoup éteignait leur PC en partant le soir et le rallumait le lendemain, si un problème urgent était à régler, il fallait attendre. Faire revenir un salarié de chez lui (hors astreinte, souvent déjà équipé pour le télétravail d’ailleurs), ça tenait du miracle, c’était le rôle des chefs en dernier ressort, genre météorite qui tombe sur la boîte. Ça n’est clairement plus le cas. On peut faire une utilisation raisonnée de ce type de débordement, appelé “flexibilité”.

Dans certaines entreprises, ça s’est très mal passé, quand le débordement est devenu la norme. J’en ai déjà parlé dans cet article . Que ce soit par le un management abusif ou par un effet d’entraînement lié à l’inculture des salariés face au télétravail, il y a eu des drames humains, inutile de le nier.

C’est autant dommage que abusivement encouragé par le management, c’est encore une fois une vision court-termiste habituel de la vie en entreprise. Épuiser un salarié pour ensuite le voir partir en arrêt-maladie et devoir le remplacer et le former à l’entreprise, c’est complètement négatif comme opération pour l’entreprise , même à court terme. Déjà que les absences liées à la Covid se sont multipliées…

Néanmoins, quand la flexibilité est utilisée raisonnablement, elle est un grand bénéfice pour l’entreprise. On finit à 21h pour une opération après les heures de bureau, le lendemain on récupère et on commence plus tard. On peut aussi commencer plus tôt, par exemple aux fonctions support ou on commence souvent tôt pour couvrir les appels des clients en matinée. Et donc on finit plus tôt, en économisant toute les contraintes qu’avaient l’entreprise à ouvrir et mobiliser du personnel à des horaires inhabituels.

De même, exit les problèmes récurrents des salles de réunion, de l’organisation des réunions internes ou avec des prestataires ou des clients. Le télétravail balaie ce problème et fait entrer massivement la réunion à distance (auparavant réservée aux cas extrêmes, type clients à l’étranger) de plein pied dans l’organisation de l’entreprise.

L’attractivité en terme de recrutement

Bien avant la pandémie, le télétravail est devenu dans certains métiers, par exemple pour les développeurs, une caractéristique déterminante dans le choix des employeurs. Ils sont une ressource rare, particulièrement les seniors immédiatement opérationnels.

Sur les sites d’emploi les annonces proposant du télétravail sont beaucoup plus consultées que les autres. Il est d’ailleurs intéressant de constater que peu d’entreprises se rendent encore compte que sur ces métiers qui peuvent s’effectuer exclusivement en télétravail, elles ne sont plus en concurrence nationale sur les profils, mais bien internationale, les meilleurs étant absorbés depuis déjà une dizaine d’années par les société américaines.

La rétention des employés pour l’entreprise

Je l’ai plusieurs fois constaté : un salarié en télétravail avec des horaires flexibles connaît bien souvent sa chance. Il y réfléchira à deux fois avant d’abandonner un poste avec ce type de caractéristiques.

Des entreprises ayant compris leur intérêt à fidéliser leurs employés permettent bien souvent à ces derniers de s’éloigner et de ne venir au bureau qu’une ou deux fois par semaine. Cela leur permet en général d’acheter un bien plus loin hors des zones tendues, en grande banlieue ou à la campagne. Il devient d’autant plus difficile de changer d’employeur pour lui ensuite.

Avec des générations récentes d’employés qui bougent plus volontiers qu’avant, le télétravail quand il est compris par les entreprises permet de réduire le turn over.

La flexibilité pour les employés

Dans des entreprises où les employés et les managers sont dans un mode davantage gagnant-gagnant et une meilleure culture du télétravail, ce dernier apporte dans l’entreprise une réelle mise en place de flexibilité.

L’organisation du télétravailleur

Disons-le clairement : pour certains métiers, l’open space est une horreur. Bruit constant, sollicitations incessantes et donc interruptions fréquentes. Les employés sont bien souvent obligés de porter un casque audio pour s’isoler au milieu des autres, ce qui – de fait – est une absurdité.

Une entreprise habituée au télétravail encourage la routine et les longues plages de travail, permettant aux métiers nécessitant de la réflexion de mieux travailler. Les réunions sont regroupées sur certains jours où les employés sont de préférence présents, pour également se voir physiquement (quand c’est possible). L’ensemble des informations de l’entreprise sont accessibles en ligne et la culture de l’écrit domine. Les outils de l’entreprise assurent que tout le monde est joignable en cas d’urgence. Mais l’idée générale est de laisser les salariés s’autonomiser.

Ce qui peut bien sûr froisser des chefs qui se croient indispensables et dont le rôle a été brusquement remis en cause, on en parlait plus haut.

La flexibilité des horaires du télétravail pendant et après la pandémie

La flexibilité des horaires est sûrement la caractéristique la plus recherchée. Pratique sérieuse d’un sport, famille avec enfants, activité extraprofessionnelle difficile à caler dans le calendrier, les raisons sont nombreuses. Commencer plus tard, finir plus tôt, disparaître 45 minutes dans la journée, les arrangements possibles sont nombreux, en concertation avec les équipes. La routine des différents salariés sur cette flexibilité rend lisible une organisation globale, là où les exceptions que devaient quémander les salariés à chaque besoin créaient des absences inattendues et constantes dans les agendas des entreprises de taille moyenne et supérieure.

En télétravail, cela ne gêne pas qu’un employé rappelle qu’il part bientôt chercher ses enfants à midi, car on sait qu’il le fait tous les jours et que son travail est fait et fiable, là où en présentiel les gens s’enfuyaient car c’était la fin de la journée. Idem avec le couvre-feu, on part faire une course avant 18 heures et on revient finir le travail en cours. Dans les métiers de la production, les lèves-tôt vont constituer les équipes du matin, les oiseaux de nuit rempliront les créneaux du soir.

Les entreprises avec une culture du télétravail permettant cette flexibilité demandent en général de la lisibilité sur l’organisation des salariés : qui commence tôt, qui finit tard, quel jour l’employé est en présentiel, quel jour il est à distance, afin de garder une cohérence au sein des services et de la lisibilité sur les agendas.

Un gain net pour l’entreprise et le salarié grâce au télétravail après la pandémie

L”actualité de la pandémie est difficile à anticiper, mais une chose est sûre, le télétravail dans de nombreuses entreprises est là pour durer. Les avantages des deux côtés décrits dans cet article ont été mis en lumière par l’impératif de télétravailler, chassant les nombreux fantasmes qui existaient auprès de ceux… qui ne le pratiquaient pas.

Flexibilité pour l’employeur et l’employé, attractivité pour l’entreprise sur un marché de l’emploi désormais mondial pour certaines ressources, coût de balais sur des pratiques comme les réunions que l’on organise désormais majoritairement à distance, le télétravail présent des avantages qui se sont imposés et perdureront après la pandémie. Les entreprises n’ayant pas négociées le virage y auront perdu quelque chose dans un environnement où la pratique du télétravail sera désormais omniprésente et que la plupart des salariés auront expérimenté.

L’auteur

Carl Chenet , architecte de systèmes informatiques Linux/Onprem/Cloud indépendant (en recherche de mission), 3 ans de télétravail régulier, entrepreneur.

Également fondateur de l’agrégateur Le Journal du hacker , du site d’emploi LinuxJobs.fr et de la newsletter Le Courrier du hacker . Modérateur sur le Chantier , lieu virtuel (Discord, forum) d’échanges d’entrepreneurs francophones.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre et/ou pour me contacter :

• Mastodon : @carlchenet
• Diaspora : @carlchenet
• Twitter : @carl_chenet

Suivre l’actualité du Logiciel Libre et Open Source francophone

Abonnez-vous au Courrier du hacker , une newsletter hebdomadaire résumant le meilleur de l’actualité francophone du Logiciel Libre et Open Source. Déjà plus de 90 numéros et plus de 2000 abonnés.

The post Le télétravail, c’est pas que pour la pandémie ! appeared first on Carl Chenet's Blog .

Original post of Carl Chenet .Votez pour ce billet sur Planet Libre .

Pour la 7ème semaine de l'année 2021, 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 !

• La compression des données
• Deux bonnes nouvelles de 2020
• Kind - Kubernetes local, sans Docker ? avec Podman !
• Déployer votre cloud personnel sous Docker avec Nextcloud
• Configurer une connexion Internet redondante
• Sortie de Plasma 5.21
• Top des sources Tech à suivre pour faire sa veille technologique
• Debian peut mieux faire
• Présentation de Caddy
• 20 outils webs indispensables pour développeurs

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

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 :)

Original post of Journal du hacker .Votez pour ce billet sur Planet Libre .

Bonjour !

Notre équipe vient de traduire le numéro 165, celui de janvier 2021, en français. Il est disponible au téléchargement ou à visionner sur notre page Numéros . De plus, vous pouvez le récupérer directement en cliquant sur la photo de couverture ci-dessous.

Parmi les bonnes choses qui y figurent, il y a une critique de Ubuntu Unity 20.10 qui paraît vraiment bien, la critique d'un EDI en BASIC, Xojo (gratuit à l'essai, payant si vous voulez créer des applis...), et une critique du jeu Waiting for the Raven (En attendant le corbeau), qui n'a malheureusement pas encore été traduit en français. L'un des tutoriels consiste en la présentation de Ventoy (pour Linux ET pour Windows), qui sert à créer une clé USB avec plein d'ISO dessus. C'est Ventoy qui les déballe lors de leur installation !

Dans ce numéro, le premier de l'année 2021, vous trouverez également, bien entendu, les tutoriels habituels (Python, Podcasts, Inkscape), la rubrique C&C, où Erik commence une petite série sur LMMS pour s'amuser et NOUS amuser, l'histoire d'un Néerlandais et ses premiers pas sous Linux il y a bien plus de vingt ans, etc., etc.

Bref, nous croyons sincèrement que ce numéro vous plaira et nous vous en souhaitons bonne lecture.

Soyez prudent et prenez bien soin de vous...

Bab, scribeur et relecteur, d52fr, traducteur et relecteur et moi, AE, traductrice et relectrice

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

La semaine dernière, alors que je baguenaudais sur le web, j’ai découvert Linux From Scratch couramment abrégé en LFS . J’ai longtemps cru qu’il s’agissait d’un langage de programmation destiné aux enfants. Mais celui-ci s’appelle Scratch tout court et il ne faut pas le confondre avec LFS qui est un projet complètement différent.

Linux From Scratch , qui signifie Linux à partir de rien , a été créé par un informaticien néerlandais qui s’appelle Gerard Beeskamp. C’est un projet mais également le titre d’un manuel de 300 pages, traduit en français et qui invite le lecteur à construire lui-même son propre système Linux. Là, on ne joue plus à la baballe dans la catégorie Ubuntu , ni même dans celle d’ Archlinux . Avec LFS, on évolue en ligue 1. Chaque programme doit être compilé, ce qui allonge de manière substantielle le temps d’installation et rend cette dernière un peu plus délicate à négocier.

LFS est un projet pédagogique qui part du principe que c’est en bricolant qu’on devient bricoleur, même si parfois, il faut percuter un extincteur… Il fournit donc une caisse à outils et un mode opératoire détaillé qui va permettre à une personne passionnée, de monter un système Linux compact, léger, sécurisé et très personnalisé.

Confiné et désoeuvré, J’ai décidé de me lancer dans l’aventure et de publier un feuilleton en plusieurs épisodes, un peu à la manière de la planète Archlinux . On verra bien ce que ça va donner. J’espère que le résultat final ne sera pas linux has crashed ! Le fil directeur sera le manuel d’installation de 300 pages en français (version systemd ). Je vous donne également le lien vers la version originale en anglais.

Sachez que vous pouvez fort bien construire votre distribution en 32-bit. Si vous la destinez à un usage serveur, ça ne pose pas de problème. Par contre, si vous prévoyez un usage Desktop , l’architecture recommandée est 64-bit.

Pas besoin d’être une développeuse professionnelle (ou un développeur professionnel) pour utiliser Linux from Scratch . Toutefois, il est nécessaire de maîtriser la ligne de commande. cd, ls, mount, mkdir et compagnie sont des termes qui doivent déjà vous parler. Si ce n’est pas le cas, il est préférable de s’arrêter là. Hein?… Tu sais utiliser la commande compagnie ? C’est un bon début…

1. Sur quelle base construire un système LFS

On va la jouer honnête. La dénomination Linux à partir de rien est pleine de promesses mais elle est mensongère. Pour construire votre LFS, vous allez vous appuyer sur une autre distribution Linux surnommée le système hôte . Vous en aurez besoin au tout début pour partitionner le disque dur et télécharger les sources. Ce peut être une Debian, une Ubuntu, une Fedora… Peu importe. Personnellement, je vais essayer avec une Archlinux. Nous allons, d’une certaine manière, parasiter le système hôte pour nous en détacher en cours de route et bâtir une distribution indépendante. Parasiter n’est peut-être pas le bon terme. Disons que le système hôte va tenir le rôle d’incubateur ou d’ utérux , si je puis me permettre d’utiliser ce néologisme!

Pour que le système hôte puisse tenir son rôle, il est nécessaire que les paquets suivants y soient déjà installés (source: manuel d’installation ):

• Bash-3.2 (/bin/sh devrait être un lien symbolique ou physique vers bash)
• Binutils-2.25 (les versions supérieures à 2.35 ne sont pas recommandées, car elles n’ont pas été testées)
• Bison-2.7 (/usr/bin/yacc devrait être un lien vers bison ou un petit script qui exécute bison)
• Bzip2-1.0.4
• Coreutils-6.9
• Diffutils-2.8.1
• Findutils-4.2.31
• Gawk-4.0.1 (/usr/bin/awk devrait être un lien vers gawk)
• GCC-6.2, y compris le compilateur C++ g++ (les versions supérieures à 10.2.0 ne sont pas recommandées, car elles n’ont pas été testées)
• Glibc-2.11 (les versions supérieures à 2.32 ne sont pas recommandées car elles n’ont pas été testées)
• Grep-2.5.1a
• Gzip-1.3.12
• Noyau Linux-3.2
• M4-1.4.10
• Make-4.0
• Patch-2.5.4
• Perl-5.8.8
• Python-3.4
• Sed-4.1.5
• Tar-1.22
• Texinfo-4.7
• Xz-5.0.0

Pour vérifier que ces programmes sont réellement présents avec les bonnes versions, exécutez le script suivant et comparez tous les numéros de version:

!/bin/bash# Script to list version numbers of critical development toolsexport LC_ALL=Cbash --version | head -n1 | cut -d" " -f2-4MYSH=$(readlink -f /bin/sh)echo "/bin/sh -> $MYSH"echo $MYSH | grep -q bash || echo "ERROR: /bin/sh does not point to bash"unset MYSHecho -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-bison --version | head -n1if [ -h /usr/bin/yacc ]; then    echo "/usr/bin/yacc -> `readlink -f /usr/bin/yacc`";elif [ -x /usr/bin/yacc ]; then    echo yacc is `/usr/bin/yacc --version | head -n1`else    echo "yacc not found"fibzip2 --version 2>&1 < /dev/null | head -n1 | cut -d" " -f1,6-echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2diff --version | head -n1find --version | head -n1gawk --version | head -n1if [ -h /usr/bin/awk ]; then    echo "/usr/bin/awk -> `readlink -f /usr/bin/awk`";elif [ -x /usr/bin/awk ]; then    echo awk is `/usr/bin/awk --version | head -n1`else    echo "awk not found"figcc --version | head -n1g++ --version | head -n1ldd --version | head -n1 | cut -d" " -f2- # glibc versiongrep --version | head -n1gzip --version | head -n1cat /proc/versionm4 --version | head -n1make --version | head -n1patch --version | head -n1echo Perl `perl -V:version`python3 --versionsed --version | head -n1tar --version | head -n1makeinfo --version | head -n1 # texinfo versionxz --version | head -n1echo 'int main(){}' > dummy.c && g++ -o dummy dummy.cif [ -x dummy ]    then echo "g++ compilation OK";else    echo "g++ compilation failed"firm -f dummy.c dummy

Voilà pour cette introduction. Dans le prochain épisode, nous allons entrer dans le vif du sujet puisque nous allons partitionner le disque dur destiné à héberger la distribution LFS. Nous allons également télécharger les premières sources.

À bientôt

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