Le blog de Seb

PassionGNU/Linux, la passion du Libre...

Jan 09, 2020

Nouvelle année et nouveau moteur pour le blog -- petit bilan 2019.

Une année se termine et une autre commence, c'est la vie, c'est comme ça. L'année 2019 à été riche encore pour moi, j'ai eu mon opération, mon garçon est arrivé en décembre, la sécu ne me reconnaît plus en accident de travail mais en simple maladie (cool de faire des réductions de charges sur le dos des contribuables), on conteste et on a de quoi le faire, maintenant vu que c'est un médecin conseil qui ne me connaît pas ni ne m'a jamais vu, c'est un peu parole contre parole... En tout cas mon docteur, elle n'est vraiment pas contente de la sécu.

Sur le plan Libre, je n'ai pas fait grand chose, un peu d'entretien pour Debian et le paquet que je maintiens officiellement, pas mal d'entretiens de paquets pour openSUSE, mais à part ça rien... Faut dire que malgré ce que la sécu dit, j'ai toujours pas mal de soucis de santé dû à mon accident.

J'ai testé pas mal de choses pour le blog, des CMS, des GSS, je dois finir les nombreux billets qui en parlent, notamment un sur Publii qui est une interface et un moteur pour générer un site static, puis aussi Grav un CMS Flat-File que j'ai testé sur une semaine.

Pelican-logo

Il y a eu des changements sur le blog, un premier en Août où je suis repassé sur Hugo et à coté je testais depuis Juin une version du site sur Pelican qui à été mise en place que récemment (hier). Ça fait un moment que je parle de Pelican disant que c'était celui qui me correspondait mieux car plus compréhensible pour moi, je disais déjà ceci en Décembre 2017. J'ai résolu les 98% des choses qui ne me convenaient pas ou qui à mes yeux merdaient, des choses dont j'arrivais pas à trouver le pourquoi du comment, là en laissant marriner, en testant sur le long terme, j'ai trouver.

Dans les choses qui n'allaientt pas je disais ceci en Août:

Ça sera non pas Pelican mais bel et bien mon premier GSS Hugo qui fera le taf.

Je voulais tenter Pelican, depuis le temps que je le testais, ça allait plutôt bien:

  • j'avais ce que je voulais en terme de fonctions (tags, sitemap, ATOM ou RSS, divers thèmes adaptables...),
  • la configuration est bien compréhensible,
  • il y a des scripts facilitant la création du site et sa maintenance (principalement sur l'automatisation de l’envoi du site sur le serveur),
  • il y a une bonne documentation,
  • le projet bouge de façon humaine, c'est-à-dire qu'on peut suivre la cadence des sorties,
  • ...

Mais car oui il y a un mais:

  • c'est tout aussi lent que Jekyll pour la "fabrication" du site ( plus ou moins 13 - 15 secondes pour compiler mon site avec ses +400 billets),
  • en locale j'avais ce que je voulais mais ça merdait une fois balancé sur le serveur (pas taper c'est sûrement moi qui merdais),
  • les thèmes ne sont pas ou peu suivis, j'ai du reste l'impression que c'est l'ensemble des thèmes et plugins qui peinent à être maintenu,
  • certaines syntaxes de Markdown ne fonctionnent pas contrairement à sous Jekyll et sous Hugo comme ~~barré~~ (entouré de deux ~),
  • ...

Pour la lenteur de "fabrication" du site, Pelican met autant voir un peu moins que Jekyll mais plus de temps que Hugo, généralement pour 400/500 billets Hugo met 500ms (0.50s) tandis que Pelican et Jekyll sont dans les 8-10s. J'ai trouvé une parade avec Pelican, c'est le "cache", je mets maintenant moins de 2 secondes, c'est toujours plus que Hugo mais ça reste convenable. En gros ça met en cache les pages, utilisant ce cache pour les pages qui sont inchangées et les autres sont compilées. Je crois de mémoire que c'est aussi le cas de Hugo, qui par défaut utilise l'option fast-rendrer.

Le problème des changements non-voulus entre le local et le site distant, était dû à une option que je n'activais pas, enfin je suppose car depuis son activation c'est parfait! L'option est RELATIVE_URLS.

Les thèmes et plugins sont suivis mais ça bouge pas ou peu car pas de chamboulements sur le moteur du GSS. Quand je regarde Jekyll c'est plus ou moins pareil, ça fait des corrections mais pas beaucoup plus.

Et pour finir la syntaxe fait partie des choses que je n'ai pas résolue, mais je vais y revenir.

On en vient donc à la partie qui continue à ne pas être parfait, la syntaxe markdown incomplète principalement, le manque de thèmes récents/modernes, l'index qui avec le thème actuelle n'est pas limité à un nombre de caractères...

Je reviens sur la syntaxe donc, j'ai des soucis d'URL qui sont en simples textes et non des liens dans le billet, en fait je parle de soucis mais ce n'est pas le cas, je devrais dire que j'ai été étonné de me trouver en face de ce comportement par rapport à ce que j'ai connu avec Jekyll et Hugo. Quand je tape https://passiongnulinux.tuxfamily.org, je m'attends à trouver https://passiongnulinux.tuxfamily.org, or ce n'est pas le cas avec Pelican contrairement à Hugo et Jekyll. Donc ce n'est pas un bug ou un manque, c'est juste le markdown utilisé, certains programmes utilisent un markdown légèrement amélioré qui fait cela automatiquement, qui oblige du coup à rajouter un symbole devant l'adresse pour que ce ne soit pas interprété comme telle, et d'autre comme Pelican utilise un markdown plus originel où il faudra ajouter l'adresse entre <> pour que ce soit interprété et convertie en adresse cliquable.

C'est donc résolu pour moi cette partie là, par contre dans la syntaxe, il ne me reste plus qu'a comprendre pourquoi les parties barrées (comme ~~partie barrée~~) ne le sont pas. Ça je ne me l'explique toujours pas.

Mise à part ça, je vais quand même positiver en disant que je suis enfin sous Pelican, j'arrive donc facilement à avoir ce que je veux comme une page archive qui regroupe tous les billets depuis le débuts (enfin ceux que je n'ai pas viré). j'ai aussi la possibilité de faire des catégories facilement en ajoutant mes fichiers.md dans des dossiers, alors que Jekyll et Hugo de ce que j'ai pu voir n'ajoutent les catégories que si on ajoute une ligne catégorie dans la partie metadata du fichier.md comme dans l'exemple ci-dessous:

---
title: My First Review
date: 2010-12-03 10:20
category: Review
---

Je n'ai pas réussi à faire des catégories en ajoutant mes billets dans des sous-dossiers sous Hugo et Jekyll, plusieurs tentatives et à chaque fois j'ai eu des soucis, j'aime pouvoir avoir la possibilité de le faire car c'est bien plus facile quand on doit changer ou faire des catégories pour un grand nombre de billets.

Voila pour les changements de cette année 2019, on verra si on reste dessus ou si on retourne sous Hugo, pour le moment j'ai exactement ce que je veux...

Jan 02, 2020

Il est Grav lui!

Grav

Quel jeu de mot pourrie, oui je n'ai pas été loin pour le faire.

Je sais pas pourquoi, je regarde de nouveau du coté des CMS, peut être que ma solution statique m'ennuie un peu, trop simple, trop routinier, j'ai donc été voir de nouveau les anciens, comme SPIP, Dotclear, Wordpress... SPIP sera certainement un choc "enfin" dans son administration, si seulement je retrouvais l'endroit où j'ai vu que l'équipe travail sur une administration bien plus moderne. Je n'arrive plus avec ce genre de CMS, il faut tout un tas de choses comme PHP, MYSQL... Je n'ai plus envie de me prendre la tête avec une base de données, c'est un blog, un simple blog pas besoin d'une armada de fonctions pour un simple blog.

J'ai relancé les Guppy, PluXml et autres, je n'y arrive pas avec, coté simplicité on y est mais il faut de suite charger dans PluXml un semblant d'éditeur et je n'en trouve pas à mon goût. J'ai goûté au markdown et c'est dure d'en revenir, c'est un langage simple, compréhensible, ça ressemble beaucoup mine de rien à l'éditeur de SPIP et celui-ci a eu longtemps ma préférence.

Donc il me faut un truc aussi simpliste que PluXml avec un éditeur markdown, j'ai trouvé, ou plutôt c'est Alionet qui m'a mit sur le bon chemin. Ça s'appel Grav et c'est un mixte entre sites dynamiques à la Wordpress et sites statiques comme j'utilise actuellement, ça n'utilise pas de base de données proprement parlé, du moins pas comme on le sous-entend habituellement, pas de MYSQL ou de SQLITE, non à la place ce sont des fichiers plats, un CMS Flat-file comme peut l'être PluXml. Cette fois et contrairement à PluXml, les articles ne sont pas dans un format XML mais de simples fichiers markdown encore plus simple pour être lisibles par l'humain.

Mais avant de parler proprement de Grav, on va situer un peu mes besoins et le contexte. J'utilise un générateur de sites statiques depuis maintenant 2 ans, j'en ai changé mais principalement j'utilise Hugo. Il y a toujours des points positifs et des négatifs, dans les +, on a:

  • la rapidité,
  • la simplicité extrême,
  • besoin juste d'un serveur pour stocker le site, pas besoin de PHP ou autre, seulement un serveur apache ou s'approchant,
  • la légèreté,
  • la sécurité,
  • on travaille directement avec les outils de notre PC, un simple éditeur,
  • on a aussi le fait qu'on ne s'occupe que de faire vivre notre site sans la gestion, pas besoin de mettre le moteur du site à jour...

dans les moins, on a:

  • on ne peut modifier le site que sur la machine où on a notre "build", à moins de mettre celui-ci sur une clé et de se promener avec,
  • c'est du statique, donc on oublie tout ce qui est en dynamique comme les commentaires, à moins là encore de contourner le problème...,
  • besoin pour la moindre correction de recommencer toute l'étape de "compilation" du site,
  • pour ma part c'est tout.

Quand je suis parti sur du statique, c'est que je voulais avoir le plus rapide, le plus sécurisé, le plus léger, j'en ai eu pour mon grade, j'ai eu exactement ce que j'avais demandé, alors j'admets que pour l'heure le changement n'est pas encore d'actualité, c'est juste l'excitation de changer mais ce que l'on me promet donne le tournis. On me dit que je vais avoir un Wordpress sans base de données et avec un éditeur markdown, où je signe?

Pour l'installer rien de compliqué, on décompresse l'archive, j'ai pris l'archive Grav+admin pour me simplifier la vie car sinon on peut le gérer avec les fichiers et des commandes à la linux. Il ne lui faut seulement un PHP récent pour tourner et rien d'autre.

Je vais le tester en douce, je ferai des captures d'images pour le montrer, on verra si ça arrive à me détacher de mon eldorado qu'est le site statique.

Jan 01, 2020

"Charger un PHP moderne pour son site chez Tuxfamily"

Comme vous pouvez le savoir, je suis chez Tuxfamily pour mon blog, c'est très bien et je les remercie vivement. Le soucis comme il peut se présenter et que je ne m'en étais pas rendu compte n'ayant actuellement que le besoin d'un serveur Web (Apache ou autre) puisque j'utilise HUGO pour générer mon site en static, c'est que pour des applications du type CMS comme Wordpress et tant d'autres, il nous faut PHP et la version par défaut de PHP n'est plus supportée par des CMS trop modernes comme pour Grav qui nous engueule:

You are running PHP 5.6.40-12+0~20190902.20+debian10~1.gbpc72558, but Grav needs at least PHP 7.1.3 to run.

Il suffit d'ajouter ceci à notre .htaccess:

AddType application/x-httpd-php7 .php

Source

Dec 29, 2019

"Convertir plusieurs images en PDF."

J'ai eu besoin d'envoyer des images que j'avais déjà numérisé dans un format .JPG mais dans un format .PDF, ne cherchez pas c'est de l'administratif et puis ce format me permet de regrouper plusieurs images ensemble et dans un seul fichier.

Voici donc quelques commandes pour convertir des images au format PDF.

Tout d'abord installer imagemagick:

sudo apt-get install imagemagick

Conversion de plusieurs images au format PDF:

$ convert img1.jpg img2.jpg img3.jpg  file.pdf

Définition de la dimension de la page:

$ convert -page 800x600 img1.jpg img2.jpg img3 file.pdf

Définition de la dimension de l'image:

$ convert -size 800x600  1600x1200 img1.jpg img2.jpg img3 file.pdf

Redimensionner l'image:

$ convert -resize 50% img1.jpg img2.jpg file.pdf

Conversion d'un grand nombre de fichiers au format d'image:

$ convert *.jpg file.pdf

Dec 29, 2019

"Ouverture de l'élection au conseil d'administration d'openSUSE 2019-2020 - Appel à candidatures"

C'est l'heure des élections !

Deux sièges sont à pourvoir au sein du conseil d'administration d'openSUSE. Gertjan Lettink a terminé son deuxième mandat. Simon Lees a terminé son premier mandat et il peut donc se présenter de nouveau comme candidat au Conseil s'il le souhaite.

Le calendrier des élections est le suivant :

Phase 0

5 décembre 2019

  • Annonce de l'élection du Conseil d'administration d'openSUSE 2019-2020

  • Appel pour les nominations et les candidatures au conseil d'administration

  • Campagne d'adhésion. Devenez un membre openSUSE. Profitez de l'occasion pour faire une demande d'adhésion à openSUSE pendant cette phase (afin de voter ou de vous présenter comme candidat).

25 décembre 2019

  • Clôture des nominations et des candidatures au Conseil d'administration

Phase 1

26 décembre 2019

  • Annonce de la liste finale des candidats
  • Début de la campagne
  • La campagne d'adhésion se poursuit, possibilité de faire une demande d'adhésion à openSUSE, mais les membres ne pourront voter et ne pourront pas se présenter comme candidats.

Phase 2

16 janvier 2020

*Les scrutins sont ouverts : Veuillez voter pendant ce temps

  • La campagne se poursuit

31 janvier 2020

  • Fermeture des scrutins

1er février 2020

  • Annonce des résultats

Le Comité des élections est composé d'Edwin Zakaria et d'Ish Sookun.

Seuls les membres d'openSUSE sont éligibles. Toutefois, les membres du comité d'élection ne sont pas admissibles à se présenter afin d'éviter les conflits d'intérêts. Pour postuler à un poste au sein du conseil d'administration d'openSUSE, veuillez envoyer un e-mail à :

  • opensuse-project@opensuse.org et * election-officials@opensuse.org

Si un membre désire proposer la candidature de quelqu'un d'autre, veuillez en informer le comité d'élection et les responsables communiqueront avec le candidat pour lui demander s'il désire se porter candidat au conseil.

Le comité d'élection lance un appel de candidatures et de candidatures pour le conseil d'administration d'openSUSE.

Merci à ma source, le site Alionet.

← Previous Next → Page 3 of 98