Depuis que j'ai commencé ma mission chez la DINUM, je me retrouve à rencontrer de nombreuses personnes en présentiel.

En ligne — sur Internet, le partage d'informations personnelles est simple et fluide. Je peux facilement communiquer mon prénom, mon nom, et des URLs avec précision. C'est pourquoi j'ai créé https://sklein.xyz, porte d'entrée vers toutes les informations me concernant.

Quand une rencontre s'effectue en présentiel, les choses sont plus compliquées.

Il y a deux semaines, par exemple, j'échangeais avec un collègue assis en face de moi. Après plusieurs minutes, il a lancé la discussion et a cherché à mieux me connaître. Ma présentation a été maladroite et je doute qu'il ait retenu mon prénom ou mon nom...

Lorsque j'ai commencé à l'interroger à mon tour, j'ai découvert qu'il était l'un des deux créateurs du projet Open Food Facts, un projet que j'admire depuis plusieurs années.

Cette expérience m'a fait prendre conscience une nouvelle fois de deux choses : j'aurais vraiment apprécié avoir des cartes de visite à partager, et si je n'avais pas posé de questions, j'aurais manqué l'opportunité d'échanger pendant près d'une heure sur un projet qui me passionne.

Suite à cela, j'ai pour objectif :

• Concevoir une carte de visite personnelle
• Créer un sticker personnalisé à apposer sur le capot de mon Thinkpad T14s

Par le passé, j'avais le sticker suivant sur mon laptop, acheté chez Redbubble :

Ce dessin suscitait des discussions autour du Yak shaving à presque chacune de mes nouvelles rencontres. Je trouvais cela à la fois amusant et efficace pour briser la glace.

Informations que je souhaite intégrer sur ces supports :

• Simplement l'URL : https://sklein.xyz
• Et mon avatar_stephane-512x512.jpg

Rien de plus.

Pour me permettre d'analyser les sources de connexion (tracking), je souhaite :

• Imprimer l'URL https://sklein.xyz/1/ sur le sticker de laptop
• Imprimer l'URL https://sklein.xyz/2/ sur les cartes de visite

Un collègue m'a partagé le projet Marker (https://github.com/VikParuchuri/marker) :

Marker converts documents to markdown, JSON, and HTML quickly and accurately.

• Converts PDF, image, PPTX, DOCX, XLSX, HTML, EPUB files in all languages
• Formats tables, forms, equations, inline math, links, references, and code blocks
• Extracts and saves images
• Removes headers/footers/other artifacts
• Extensible with your own formatting and logic
• Optionally boost accuracy with LLMs
• Works on GPU, CPU, or MPS

source

Voici comment fonctionne Marker :

Marker is a pipeline of deep learning models:

• Extract text, OCR if necessary (heuristics, surya)
• Detect page layout and find reading order (surya)
• Clean and format each block (heuristics, texify, surya)
• Optionally use an LLM to improve quality
• Combine blocks and postprocess complete text

source

Voici-ci dessous, une partie de la liste de labels d'Issues que l'équipe tech de Spacefill utlisait sous GitLab. Cette liste de labels est le fruit d'un travail itératif d'environ 15 personnes, sur une période de 4 ans.

Voici comment cette liste a été élaborée :

• Au départ, quelques labels ont été créés de manière organique par 3 développeurs et un product manager.
• Après 3 mois d'usage, une page de documentation nommée "GitLab Spacefill labels" a été ajoutée au handbook de l'équipe.
• Ensuite, au fur et à mesure des nouvelles problématiques rencontrées et de l'évolution des workflows, ce fichier de documentation a été amendé plus de 70 fois en 3 ans, par 11 contributeurs différents.
• Ce document était modifié suivant le même processus que le reste du handbook et le code :
  • Une personne commençait par créer une issue pour décrire une problématique
  • Ensuite, cette même personne ou une autre faisait une proposition d'évolution du processus par la rédaction d'une Merge Request qui modifiait cette page de documentation
  • Puis cette Merge Request entrait dans une phase de review par l'équipe, était corrigée, amendée...
  • Et finalement, quand cette Merge Request était approuvée par toute l'équipe, elle était mergée et ensuite respectée par tous

J'ai conservé cette liste afin de pouvoir l'utiliser comme source d'inspiration ou de fondation pour mes prochains projets en équipe.

Pour ceux qui souhaitent s'en inspirer, je recommande de ne pas adopter cette liste intégralement d'emblée. Privilégiez plutôt une sélection ciblée des labels qui correspondent à vos processus actuels, puis incorporez progressivement de nouveaux labels selon l'évolution de vos besoins.

Mon expérience m'a démontré que la mise en place de processus dans une organisation humaine fonctionne mieux par petites étapes successives. Cette approche incrémentale s'avère bien plus efficace que de tenter d'imposer en bloc un processus complet qui risquerait d'être inadapté à votre contexte spécifique.

Voici cette liste.

---

Labels pour indiquer les types d'issue

Une issue doit avoir dans tous les cas un type et un seul type.

• type::user-story : une issue qui apporte une fonctionnalité à l'application
• type::improve : une issue qui apporte une amélioration mineure à une fonctionnalité existante, qui est plus simple de ne pas exprimer sous forme d'une user story, et qui bien sûr n'est pas un bug.
• type::documentation-and-process : problème ou amélioration d'un process ou d'une documentation interne (les deux sujets documentation et processus sont liés parce que les processus sont documentés). La documentation du logiciel à destination des usagers de l'application n'entre pas dans cette catégorie, elles sont du type user-story, improve ou bug.
• type::enabler : un changement qui n'apporte pas directement de valeur aux utilisateurs de l'application. Ce type est utilisé pour des issues dont le but est d'améliorer l'expérience des développeurs (voir définitions : SAFe Enablers,Les enablers en agile)
• type::technical-debt : definition, label à utiliser, par exemple pour des issues dont le bug est d'upgrader une librairie, d'améliorer une implémentation, ou une proposition de refactoring… Ce label ne doit pas être utilisé pour des issues "produit".
• type::support-ops : pour les tâches de support qui ne nécessitent généralement pas de merge request, par exemple : des migrations de données, des corrections de données, des extractions de données…
• type::spike : voir la definition
• type::meta : pour des issues de type "meta", par exemple, des issues dont le but est de créer d'autres issues, de faire de l'affinage d'issues, ou organiser des rituels…
• type::meta-spec-writing : pour des issues dont l'objectif est de créer des issues ou des Epic, dont le but est de rédiger des spécifications techniques, ce sont des sortes d'issues de type "meta", mais plus spécifiques.

• type::bug : pour des issues qui décrivent des dysfonctionnements de l'application
• type::bug-job-CI : pour des issues qui décrivent des bugs de CI

Labels pour indiquer la priorité des issues

• priority::critical : une issue qui doit obligatoirement être traitée tout de suite par un développeur
• priority::24h : une issue qui doit être traitée d'ici 24h
• priority::7days : une issue qui doit être traitée d'ici à 1 semaine

Labels de workflow

Une issue doit avoir un et seulement un label de type workflow, un et un seul label de type product-review.

• Draft
  • workflow::need-product-specs : l'issue doit être spécifiée par un membre de l'équipe produit
  • workflow::need-design : l'issue a besoin de wireframe, design, …
  • workflow::need-tech-specs : l'issue doit être affiner par un membre de l'équipe tech
• To do
  • workflow::ready-for-development : l'issue est prête à être implémentée
  • workflow::to-be-continued : l'issue a été commencée, mais mise en pause parce que le développeur est assigné sur une autre issue.
  • workflow::doing : un développeur est en train de travailler sur cette issue
  • workflow::ready-for-first-review : l'issue est prête à être review par un développeur
  • workflow::ready-for-maintainer-review : l'issue est prête à être review par un maintainers
  • workflow::blocked : l'issue est bloquée Par exemple :
    • l'issue est commencée, elle peut avoir une merge request de prête, mais le développeur ne peut pas la terminer, car elle dépend d'une autre Merge Request en cours d'élaboration ;
    • l'auteur de l'issue attend une réponse d'une personne externe de l'équipe produit ou tech, par exemple un client.
  • workflow::ready-for-merge : l'issue a été review et est prête à être mergé
  • need-cto : l'issue est bloquée parce qu'elle est en attente d'une validation par le CTO
• Product review
  • product-review::needed : indique que l'issue doit être review par un membre de l'équipe produit
  • product-review::not-needed : indique que l'issue n'a pas besoin d'être review par l'équipe produit
  • product-review::pending : issue en attente de review par un membre de l'équipe produit
  • product-review::feedback : une demande de correction a été émise par un membre de l'équipe produit
  • product-review::approved : la Merge Request a été review et validée par un membre de l'équipe produit avec plus aucune demande de correction

Labels d'intégration dans des boards

• board-product-refinement : pour intégrer des issues dans un Kanban board qui contient une liste d'issues que l'équipe produit doit affiner
• board-tech-refinement : pour intégrer des issues dans un Kanban board qui contient une liste d'issues que l'équipe tech doit affiner
• board-support : pour intégrer des issues dans un Kanban board qui contient une liste d'issues de support qui traitent des demandes externes à l'équipe tech ou produit.
• board-cto : utilisé par le CTO pour suivre des issues "cross team"

Labels divers

• first-contribution : pour identifier des issues en théorie facilement réalisables par un nouveau développeur en phase d'onboarding.
• sprint-planning : pour les issues de type meta, dont l'objectif est d'organiser le rituel Sprint Planning.
• sprint-retrospective : pour les issues de type meta, dont l'objectif est d'organiser le rituel Sprint Retrospective.
• sprint-retro-follow-up : pour identifier les sujets qui ont été remontés lors d'une session de Sprint Retrospective.
• triage : pour identifier les issues qui doivent être triées, c'est-à-dire, décider si l'issue doit être abandonnée pour être placée dans un backlog.
• need-to-be-planned : pour identifier des issues validées, mais qui doivent être planifiées, c'est-à-dire, être ajoutées dans un sprint
• danger : pour identifier des issues qui doivent être traitées avec prudence, qui par exemple risquent de détruire des données.
• tech-refinement : pour identifier une issue qui doit être affiner par l'équipe tech, mais qui n'a pas encore été ajoutée dans le board-tech-refinement.
• tech-refinement-removed : pour identifier des issues qui étaient dans un board-tech-refinement mais qui n'ont pas été affiné par manque de temps et donc repoussées à une future session.
• security : pour identifier des issues en lien avec la sécurité informatique, par exemple, un risque de fuite de données, de perte de données, d'intrusion…
• version-outdated : pour identifier les issues dont l'objectif est la mise à jour de librairies ou de services.

Label de compétences nécessaires

Liste de labels peu utilisés, ils permettaient d'identifier les compétences techniques nécessaires pour pouvoir traiter l'issue.

• skills:ansible
• skills:terraform
• skills:nodejs
• skills:postgraphile
• skills:html/css
• skills:docker
• skills:gitlab-ci
• skills:docker
• skills:dev-ops
• skills:postgres
• skills:postgres-rls
• skills:postgres-rbac
• skills:postgresql-plsql
• skills:postgresql-policy
• skills:reactjs
• skills:shellscript
• skills:sql

Je viens de publier un playground au sujet de Gitleaks : gitleaks-playground.

Mes objectifs étaient les suivants :

• Tester la détection d'une clé privé ssh
• Tester la détection d'un password
• Tester la configuration de Gitleaks dans un git hook pre-commit
• Tester comment ignorer les secrets présents dans certains fichiers

J'ai compris que les règles de détections de secrets sont définies dans le fichier /config/gitleaks.toml.

J'ai constaté que par défaut, Gitleaks ne détecte pas ce password :

export PASSWORD="aeFeaxoo3phaikae"

pour corriger ce problème, j'ai été obligé de modifier le niveau de sensibilité de l'entropy de la règle generic-api-key dans le fichier /.gitleaks.toml:

[[rules]]
id = "generic-api-key"
entropy = 2

Le paramètre entropy est définit ici par défaut à 3.5.

J'ai compris qu'il est possible d'ignorer la détection d'un secret soit en ajoutant les Fingerpritn dans .gitleaksignore ou alors en ignorant totalement des fichiers, comme ceci dans .gitleaks.toml :

[[allowlists]]
description = "Ignore README"
paths = [
    "README.md"
]

[[allowlists]]
description = "Ignore .secret"
paths = [
    ".secret"
]

Pour configurer le git hooks, j'ai préféré de ne pas utiliser pre-commit afin de ne pas dépendre d'un projet en python. J'utilise un simple script shell : /git-hooks/pre-commit.

Pour activer ce hook, j'utilise la commande git config core.hooksPath git-hooks.

Je trouve cela plutôt simple avec aucune dépendance.

Ici dans le code source de Open WebUI, #JaiDécouvert Pyodide :

Pyodide is a Python distribution for the browser and NodeJS based on WebAssembly.

source

Depuis un an, j'ai pris conscience d'une difficulté inhérente aux organisations qui suivent le paradigme Multirepos, difficulté dont je ne m'étais pas rendu compte auparavant : décider où publier ses issues !

J'ai observé que dès qu'une organisation commence à utiliser plusieurs repositories, la question de l'endroit où créer de nouvelles issues se pose. Par exemple :

• Où poster une issue d'amélioration qui nécessite des changements dans le repository A et B ?
• Où créer une issue d'une proposition d'un process qui ne concerne pas spécifiquement le code source d'un projet hébergé dans un repository ?
• Où créer une issue dont le but est de créer un nouveau service ?

Quand une organisation suit le paradigme Monorepo avec issues colocalisées et utilise, comme je l'explique dans la note "Nom et arborescence de Monorepo" un nom non spécifique, alors la question de l'endroit où publier ses issues ne se pose pas ! Il suffit de publier l'issue dans le Monorepo (par exemple sur GitHub, GitLab ou Forgejo).

Le gestionnaire d'issue du Monorepo est un point de schelling, c'est-à-dire un endroit où tous les développeurs convergent naturellement en l'absence de communication explicite pour trouver et créer des issues.

Ce paradigme évite des débats à propos de l'endroit où publier les issues.

Je suis un adepe du paradigme Monorepo, de la documentation colocalisée et des issues colocalisées.

Je conseille de nommer le repository avec le nom de l'organisation.

Par exemple, si mon organisation se nomme « Dummy Tech » et si elle utilise GitLab, alors je conseille d'utiliser le slug dummy-tech, ce qui donne gitlab.com/dummy-tech/dummy-tech/ et « Dummy Tech Monorepo » comme titre de repository.

La neutralité de ce nom facilite les décisions concernant ce qui peut ou non être inclus dans le repository, sans être limité par un nom trop restrictif. Il est flexible face à l'évolution du projet. Il permet d'éviter bien des débats à propos du nommage.

En 2018, sur GitHub, j'ai découvert un exemple de monorepo d'une organisation. Cet exemple m'a servi de base et je l'ai fait évoluer quand je travaillais chez Spacefill.

Voici un exemple d'arborescence de monorepo que j'aime utiliser :

dummy-tech
├── deployments
│   ├── prod
│   └── sandbox
├── ci
├── docs
├── playgrounds
│   ├── playground_a
│   └── playground_b
├── services
│   ├── service_a
│   ├── service_b
│   └── service_c
└── tools
    ├── tool_a
    ├── tool_b
    └── tool_c

Je gère actuellement un projet comprenant 8 Merge Requests empilées (Stacked PRs) en cours de review, s'étendant sur une période d'environ deux mois.

Au fur et à mesure que je continue à travailler sur ce projet, j'ai effectué à plusieurs reprises des améliorations ou des corrections qui concernent des commits déjà en cours de review.

Si ces Merge Request étaient mergés, cela ne me poserait pas de problème. Je proposerai de nouvelles Merge Request avec ces changements.

Dans la situation actuelle, si je souhaite effectuer une amélioration dans la Merge Request numéro 2, je préfère modifier directement cette Merge Request plutôt que d'en créer une nouvelle. Cette approche me semble plus logique et propre, surtout pour une Merge Request qui n'a pas encore été review.

En pratique, la modification de la Merge Request numéro 2 est une tâche fastidieuse. Si je modifie cette Merge Request, je vais devoir propager mon changement sur 6 branches et résoudre de nombreux conflits. J'ai peur de faire une erreur.

Cette opération est très pénible.

C'est pour cette raison que j'ai étudié dernièrement Stacked Git et Jujutsu.

Je me demande quel outil serait le plus adapté pour gérer ma problématique.
git-stack, git-branchless, Stacked Git ou Jujutsu 🤔.

Suite à la lecture du thread "jj tips and tricks" Lobster, je suis tombé dans un rabbit hole (1h30) : #JaiLu les articles ci-dessous au sujet de Jujutsu.

• "What I've learned from jj" (134 commentaires Hacker News et 57 commentaires Lobster)
  • Et ses sous-articles :
    • "First-class conflicts"
    • "Why some of us like "interdiff" code review"
    • "In Praise of Stacked PRs"
      • "Small CLs"
• "jj tips and tricks"

Quelques commentaires au sujet de l'article "What I've learned from jj"

Along with describing and making new changes, jj squash allows you to take some or all of the current change and “squash” it into another revision. This is usually the immediate parent, but can be any revision.

...

With jj squash, the current change is pushed into whatever target revision you want. And if that change has children, they’ll all be automatically rebased to incorporate the updated code, no additional work is needed.

source

J'ai hâte de tester si, à l'usage, c'est sensiblement plus simple qu'avec Git 🤔.

Conflict resolution

One of the consequences of being able to modify changes in-place is that all subsequent changes need to be rebased to account for the updated parent. If there were a sequence s -> t -> u -> v and you’d modified t, jj will automatically rebase the rest: s -> t' -> u' -> v'. This includes conflicts, if any arise. The difference from git is that conflicts are not a stop-the-world event! You’ll see in the jj log output that changes have a conflict, but it won’t prevent a command (like an explicit or implicit rebase) from running to completion. You get to choose when and how to resolve the conflicts afterward. I found this a surprising benefit: rebases are already less stressful because of how easy undo is, but now I’m no longer interrupted and forced to resolve conflicts immediately.

source

Cette simplicité annoncée me surprend vraiment. J'ai du mal à imaginer le fonctionnement, sans doute parce que je suis trop habitué à utiliser Git. J'ai l'impression que c'est de la magie !

J'ai hâte de tester !

... efforts to add Change-ID as a supported header in git itself to enable durable change tracking on top of commits.

source

J'ai découvert cette initiative, je trouve cela très intéressant👌.

---

Un commentaire au sujet de l'article "First-class conflicts"

First-class conflicts

...

Unlike most other VCSs, Jujutsu can record conflicted states in commits. For example, if you rebase a commit and it results in a conflict, the conflict will be recorded in the rebased commit and the rebase operation will succeed. You can then resolve the conflict whenever you want. Conflicted states can be further rebased, merged, or backed out. Note that what's stored in the commit is a logical representation of the conflict, not conflict markers; rebasing a conflict doesn't result in a nested conflict markers (see technical doc for how this works).

source

Je trouve cela très intéressant.

Voici une commande pour extraire un patch avec l'inclusion des "Conflict markers" (je n'ai pas encore testé) :

$ jj diff --include-conflicts > conflicts.patch

---

Un commentaire au sujet de l'article "In Praise of Stacked PRs"

“Stacked PRs” is the practice of breaking up a large change into smaller, individually reviewable PRs which can depend on each other, forming a DAG.

source

Je suis ravi de découvrir que le terme "Stacked PRs" existe pour décrire le concept que j'expliquais souvent quand j'étais chez Spacefill.

---

En lisant ces articles, #JaiDécouvert :

• git-rerere
• Mercurial Changset Evolution
• git-machete
• git-stack (git-stack)
• GitBulter (https://github.com/gitbutlerapp/gitbutler)

et j'ai "redécouvert" :

• git-branchless git-branchless

#JeSouhaiteLire :

• Working branches and the JJ "way"
• Use the Mikado Method to do safe changes in a complex codebase

Je continue mon travail de mise à niveau en Kubernetes.

Je viens de réaliser que Helmfile ne fait pas directement partie du projet Helm. Je trouve cela surprenant. Ces deux projets sont réalisés par deux equipes différentes :

• Dépôt GitHub de Helm : https://github.com/helm/helm/
  • Développeurs principaux :
    • Matt Butcher basé aux États-Unis
    • Adam Reese basé aux États-Unis
• Dépôt GitHub de Helmfile : https://github.com/helmfile/helmfile/
  • Développeurs principaux :
    • Yusuke Kuoka basé au Japon
    • yxxhero basé en Chine

D'après ce que je comprends, si je simplifie, Helmfile est pour Helm l'équivalent de ce qu'est docker-compose.yml pour Docker.

---

Je m'intéresse aujourd'hui à Helmfile parce que je souhaite effectuer une tâche qui correspond au use-case numéro 2 décrit dans la documentation :

ArgoCD has support for kustomize/manifests/helm chart by itself. Why bother with Helmfile?

The reasons may vary:

• 1. You do want to manage applications with ArgoCD, while letting Helmfile manage infrastructure-related components like Calico/Cilium/WeaveNet, Linkerd/Istio, and ArgoCD itself.
• 2. You want to review the exact K8s manifests being applied on pull-request time, before ArgoCD syncs.
• 3. This is often better than using a kind of HelmRelease custom resources that obfuscates exactly what manifests are being applied, which makes reviewing harder.

source

Suite à cette lecture, voici comment j'ai mis en application une partie du use-case 2.

J'ai ce helmfile.yaml :

environments:
  dev:
    values:
      - version: 6.1.0
  production:
    values:
      - version: 6.1.0
---
repositories:
  - name: open-webui
    url: https://helm.openwebui.com/
---
releases:
  - name: openwebui
    namespace: {{ .Namespace }}
    chart: open-webui/open-webui
    values:
      - ./env.d/{{ .Environment.Name }}/values.yaml
    version: {{ .Values.version }}

Et ensuite, j'ai exécuté :

$ helmfile template -e dev --output-dir-template $(pwd)/gitops/{{.Release.Name}}
Adding repo open-webui https://helm.openwebui.com/
"open-webui" has been added to your repositories

Templating release=openwebui, chart=open-webui/open-webui
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/templates/service-account.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/service.yaml
wrote .../gitops/openwebui/open-webui/templates/service.yaml
wrote .../gitops/openwebui/open-webui/charts/pipelines/templates/deployment.yaml
wrote .../gitops/openwebui/open-webui/templates/workload-manager.yaml
wrote .../gitops/openwebui/open-webui/templates/ingress.yaml

Cela me permet ensuite de pouvoir observer avec précision ce qui va être déployé par ArgoCD.

Depuis un an que j'effectue des missions Freelance, j'ai régulièrement besoin d'effectuer des changements dans des projets pour intégrer mes pratiques development kit, telles que l'utilisation de Mise, .envrc, docker-compose.yml, un README guidé, etc.

Généralement, ces missions Freelance sont courtes et je ne suis pas missionné pour faire des propositions d'amélioration de l'environnements de développement.

En un an, j'ai été confronté à cette problématique à cinq reprises.

Jusqu'à présent, j'ai utilisé la méthode suivante :

• J'ai intégré mon development kit dans une branche sklein-devkit
• Cette branche m'a ensuite servi de base pour créer des branches destinées à traiter mes issues, nommées sous la forme sklein-devkit-issue-xxx
• Et pour finir, je transfère mes commits avec git cherry-pick dans une branche du type issue-xxx que je soumettais dans une Merge Request ou Pull Request.

À la base, ce workflow de développement n'est pas très agréable à utiliser, et devient particulièrement complexe lorsque je dois effectuer des git pull --rebase sur la branche sklein-devkit !

Dans les semaines à venir, pour le projet Albert Conversation, je dois trouver une solution élégante pour gérer un cas similaire. Il s'agit de maintenir des modifications (série de patchs) du projet https://github.com/open-webui/open-webui qui :

• seront soit intégrées au projet upstream après plusieurs semaines ou mois
• soit resteront spécifiques au projet Albert Conversation et ne seront jamais intégrées en upstream, comme par exemple l'intégration du Système de Design de l'État.

Je me souviens avoir été marqué par l'histoire du projet Real-Time Linux mentionnée dans l'épisode 118 du podcast de Clever Cloud : les développeurs de Real-Time Linux ont maintenu pendant 20 ans toute une série de patchs avant de finir par être intégrés dans le kernel upstream (source : la conférence "PREEMPT_RT over the years") !

Voici la liste des patchs maintenus par l'équipe Real-Time Linux :

└── patches
    ├── 0001-arm-Disable-jump-label-on-PREEMPT_RT.patch
    ├── 0001-ARM-vfp-Provide-vfp_state_hold-for-VFP-locking.patch
    ├── 0001-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
    ├── 0001-hrtimer-Use-__raise_softirq_irqoff-to-raise-the-soft.patch
    ├── 0001-powerpc-Add-preempt-lazy-support.patch
    ├── 0001-sched-Add-TIF_NEED_RESCHED_LAZY-infrastructure.patch
    ├── 0002-ARM-vfp-Use-vfp_state_hold-in-vfp_sync_hwstate.patch
    ├── 0002-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
    ├── 0002-locking-rt-Remove-one-__cond_lock-in-RT-s-spin_trylo.patch
    ├── 0002-powerpc-Large-user-copy-aware-of-full-rt-lazy-preemp.patch
    ├── 0002-sched-Add-Lazy-preemption-model.patch
    ├── 0002-timers-Use-__raise_softirq_irqoff-to-raise-the-softi.patch
    ├── 0002-tracing-Record-task-flag-NEED_RESCHED_LAZY.patch
    ├── 0003-ARM-vfp-Use-vfp_state_hold-in-vfp_support_entry.patch
    ├── 0003-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
    ├── 0003-locking-rt-Add-sparse-annotation-for-RCU.patch
    ├── 0003-riscv-add-PREEMPT_LAZY-support.patch
    ├── 0003-sched-Enable-PREEMPT_DYNAMIC-for-PREEMPT_RT.patch
    ├── 0003-softirq-Use-a-dedicated-thread-for-timer-wakeups-on-.patch
    ├── 0004-ARM-vfp-Move-sending-signals-outside-of-vfp_state_ho.patch
    ├── 0004-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
    ├── 0004-locking-rt-Annotate-unlock-followed-by-lock-for-spar.patch
    ├── 0004-sched-x86-Enable-Lazy-preemption.patch
    ├── 0005-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
    ├── 0005-sched-Add-laziest-preempt-model.patch
    ├── 0006-drm-i915-Drop-the-irqs_disabled-check.patch
    ├── 0007-drm-i915-guc-Consider-also-RCU-depth-in-busy-loop.patch
    ├── 0008-Revert-drm-i915-Depend-on-PREEMPT_RT.patch
    ├── 0053-serial-8250-Switch-to-nbcon-console.patch
    ├── 0054-serial-8250-Revert-drop-lockdep-annotation-from-seri.patch
    ├── Add_localversion_for_-RT_release.patch
    ├── ARM__Allow_to_enable_RT.patch
    ├── arm-Disable-FAST_GUP-on-PREEMPT_RT-if-HIGHPTE-is-als.patch
    ├── ARM__enable_irq_in_translation_section_permission_fault_handlers.patch
    ├── netfilter-nft_counter-Use-u64_stats_t-for-statistic.patch
    ├── POWERPC__Allow_to_enable_RT.patch
    ├── powerpc_kvm__Disable_in-kernel_MPIC_emulation_for_PREEMPT_RT.patch
    ├── powerpc_pseries_iommu__Use_a_locallock_instead_local_irq_save.patch
    ├── powerpc-pseries-Select-the-generic-memory-allocator.patch
    ├── powerpc_stackprotector__work_around_stack-guard_init_from_atomic.patch
    ├── powerpc__traps__Use_PREEMPT_RT.patch
    ├── riscv-add-PREEMPT_AUTO-support.patch
    ├── sched-Fixup-the-IS_ENABLED-check-for-PREEMPT_LAZY.patch
    ├── series
    ├── sysfs__Add__sys_kernel_realtime_entry.patch
    └── tracing-Remove-TRACE_FLAG_IRQS_NOSUPPORT.patch

46 files

J'ai été impressionné, je me suis demandé comment cette équipe a réuissi à gérer ce projet aussi complexe sur une si longue durée sans finir par se perdre !

Real-Time Linux n'est pas le seul projet qui propose des versions patchées du kernel, c'est le cas aussi du projet Xen, Openvz, etc.

J'ai essayé de comprendre le workflow de développement de ces projets. Avec l'aide de Claude.ia, il semble que ces projets utilisent un outil comme quilt qui permet de gérer des séries de patchs.

Il semble aussi que Debian utilise quilt pour gérer des patchs ajoutés aux packages :

Quilt has been incorporated into dpkg, Debian's package manager, and is one of the standard source formats supported from the Debian "squeeze" release onwards.

source

J'ai creusé un peu de sujet et à l'aide de Claude.ia j'ai découvert des alternatives "modernes" à quilt.

• Git lui-même :
  • git format-patch pour créer des séries de patches
  • git am pour appliquer des patches
  • git range-diff pour comparer des séries de patches
  • Branches de fonctionnalités + git rebase -i pour organiser les commits
• Stacked Git (https://stacked-git.github.io/) :
  • Conçu spécifiquement comme une alternative moderne à Quilt
  • S'intègre mieux avec Git
  • Maintient une pile de patches comme Quilt mais dans l'écosystème Git
• Topgit (https://github.com/mackyle/topgit) :
  • Gère des changements de code sous forme de piles (stacks)
  • Permet de maintenir des patches à long terme pour des forks
• Git Patchwork - (https://github.com/getpatchwork/patchwork) :
  • Système de gestion et suivi des patches envoyés par email
  • Utilisé par le noyau Linux et d'autres projets open source
• Guilt (http://repo.or.cz/w/guilt.git) :
  • Clone de Quilt implémenté comme scripts Git
  • Intégration très proche de Git
• Jujutsu :
  • Système de contrôle de version moderne basé sur Git
  • Meilleure gestion des branches et séries de patches
• Git Series (https://github.com/git-series/git-series) :
  • Outil pour travailler avec des séries de patches Git
  • Permet de suivre l'évolution des séries au fil du temps

Après avoir jeté un œil sur chacun de ces projets, j'envisage de créer un playground pour tester Stacked Git.

Depuis quelques semaines, je vois de plus en plus de sites web qui intègrent Anubis. Par exemple sur https://gitlab.gnome.org/, https://priv.au/ et à l'instant sur https://forge.libre.sh/indiehosters.

Anubis weighs the soul of your connection using a proof-of-work challenge in order to protect upstream resources from scraper bots.

source

Voici ce qu'Anubis affiche à la première connexion au site web :

Alexandre m'a partagé kubectx et kubens (https://github.com/ahmetb/kubectx) :

What are kubectx and kubens?

kubectx is a tool to switch between contexts (clusters) on kubectl faster. kubens is a tool to switch between Kubernetes namespaces (and configure them for kubectl) easily.

source

---

#JaiDécouvert Kubebuilder (https://github.com/kubernetes-sigs/kubebuilder) (from)

Kubebuilder is a framework for building Kubernetes APIs using custom resource definitions (CRDs).

source

#JaiDécouvert Krew (https://github.com/kubernetes-sigs/krew) :

Krew is a tool that makes it easy to use kubectl plugins. Krew helps you discover plugins, install and manage them on your machine. It is similar to tools like apt, dnf or brew. Today, over 200 kubectl plugins are available on Krew.

source

---

#JaiDécouvert MetalLB (https://metallb.io/) :

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

source

---

#JaiDécouvert cert-manager (https://github.com/cert-manager/cert-manager)

cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.

It supports issuing certificates from a variety of sources, including Let's Encrypt (ACME), HashiCorp Vault, and Venafi TPP / TLS Protect Cloud, as well as local in-cluster issuance.

source

J'ai publié une première version du Projet 28 - "Publier un repository playground de déploiement de Open WebUI basé sur docker-compose.yml".

https://github.com/stephane-klein/open-webui-deployment-playground/

Je vais maintenant attaquer le Projet 29 - "Publier un repository playground de déploiement de Open WebUI sur un cluster Kubernetes".

Au mois de janvier, j'ai écrit :

Voici mes prochaines #intentions d'amélioration de ma workstation :

• ...
• Essayer de remplacer les services ChatGPT ou Claude.ia par Open WebUI.
• ...

source

Le hasard de la vie fait que je commence une mission professionnelle pour la DINUM en lien avec Open WebUI : Ablert Conversation.

Au mois de décembre, j'ai déjà installé et testé rapidement Open WebUI connecté à Scaleway Generative APIs, mais je n'ai pas pris le temps de le faire avec rigueur.

Dans les prochains jours, je souhaite réaliser les projets suivants :

• Projet 28 - "Publier un repository playground de déploiement de Open WebUI basé sur docker-compose.yml"
• Projet 29 - "Publier un repository playground de déploiement de Open WebUI sur un cluster Kubernetes"

J'ai commencé à utiliser Kubernetes pour la première fois en janvier 2016. C'était dans un cadre professionnel, quand je travaillais chez Tech-Angels / Gemnasium.

Mes deux premiers projets étaient les suivants :

• Opérer et continuer à améliorer un cluster de 3 nodes basé sur OpenShift (surcouche Kubernetes de Red Hat) qui permettait d'héberger les services web de nos clients.
  L'objectif était de fournir un service un peu comme Heroku, c'est-à-dire permettre un déploiement via un simple "git push".
  Avec le recul, l'objectif ressemblait à ce que propose actuellement Clever Cloud.
• Implémenter une version OnPremise de Gemnasium propulsée par Kubernetes.

En janvier 2016, Kubernetes était un projet très jeune, avec seulement 20 mois d'existence depuis la sortie de la première version 0.2. L'écosystème était bien plus petit que maintenant. Par exemple, Helm n'était pas encore populaire.

J'ai commencé par installer la version 1.1 de Kubernetes avec les playbooks officiels Ansible.

Ce fut une expérience difficile, avec de nombreux crashs de clusters, tout particulièrement lors des montées en version.
L'expérience fut très enrichissante. Cela m'a permis de monter en compétence avec Docker, Kubernetes, Ceph…

---

J'ai ensuite utilisé Kubernetes de novembre 2018 à avril 2019, dans la team Kubernetes Kapsule de Scaleway.

La mission de cette équipe était de créer un produit qui permettait de déployer des clusters Kubernetes managés.

Je suis arrivé dans cette équipe 10 mois après le début du projet. J'ai contribué au projet pendant 5 mois, jusqu'au lancement du produit en production.

Cette fois encore, une partie du travail était de déployer des clusters Kubernetes from "scatch".

Expérience intéressante : j'ai appris à déployer des clusters Kubernetes via Kubernetes !
L'implémentation était inspirée de la méthode présentée dans cet article : Gardener - The Kubernetes Botanist.

---

Depuis avril 2019, je n'ai plus opéré de cluster Kubernetes. J'ai seulement continué à suivre de loin les actualités de cet écosystème. Je n'ai plus eu d'expérience pratique.

---

Maintenant que j'ai rejoint une mission dont le produit est déployé sur Kubernetes, je souhaite mettre à jour mes compétences pratiques dans ce domaine.

Voici quelques sujets sur lesquels je souhaite monter en compétence ces prochains mois :

• M'entrainement à utiliser et à créer des Helm Charts
• Déployer un ArgoCD pour apprendre à bien l'utiliser
• Jouer avec k3s
• Tester Postgres Operator
• Étudier et tester https://tilt.dev/
• kind (https://kind.sigs.k8s.io/)
• Grafana Tanka
• kustomize (https://github.com/kubernetes-sigs/kustomize)

Note du 21 mars 2025, publiée le 25 avril 2025.

---

J'ai écouté l'épisode « Agnes Crepet - Head of software longevity & IT chez FAIRPHONE » du 1ᵉʳ septembre 2023 du podcast "Projets Libres" (from).

Avant l'écoute de cet épisode, je pensais que Fairphone faisait du Greenwashing, mais non, pas du tout. Dans cet épisode, j'ai découvert le travail difficile réalisé par Fairphone pour :

• réaliser autant que possible des téléphones démontables et réparables
• essayer de proposer des pièces de rechange le plus longtemps possible
• essayer de maintenir des mises à jour logiciels le plus longtemps possible
• essayer d'ouvrir au maximum leur téléphone, c'est-à-dire de pouvoir installer facilement des OS customisés

J'ai trouvé Agnes Crepet très humble, elle reconnait que leurs téléphones ne sont pas parfaits, mais que Fairphone suit une philosophie de transparence et essaie de jouer au maximum le jeu de l'open-source.

Voici quelques sujets abordés dans cet épisode :

• La mission de Fairphone
• Faire sa propre version d’Android avec un support long terme
• Faire du support long terme sans perdre de fonctionnalités
• Les leçons apprises du Fairphone 2
• Le retour d’expérience sur Fairphone Open OS
• Les relations avec les communautés libres (LineageOS, etc)
• La collaboration avec /e/OS (Murena)
• Les relations avec la coopérative Commown et la location d’appareils
• La longévité matérielle chez Fairphone

J'ai toujours essayé d'acheter des smartphones qui proposent une version d'Android la plus "vanilla" possible. C'est pour cela qu'en 2015 j'ai choisi d'acheter un OnePlus One (bien moins cher que le Google Pixel).

En 2022, j'ai choisi un smartphone Oppo un peu par défaut.

Fairphone proposent des Android "vanilla".

Après avoir écouté cet épisode, je pense que mon choix est fait, maintenant j'achèterai des Fairphone même si ce ne sont pas les smartphones qui offrent le meilleur ratio prix / puissance. Je souhaite soutenir leur travail parce que j'apprécie leur philosophie, leur mission.

Étant donné que j'ai besoin d'un smartphone supplémentaire pour réinstaller les smartphones de ma compagne et de mes beaux-parents, j'ai décidé d'acheter un Fairphone 5 - 5G.

Le 21 mars 2025, j'ai commandé :

• Un Fairphone 5 - 5G - Noir Mat, 128GB, 6GB Ram à 549 €TTC

Après un mois d'utilisation, je suis très satisfait et j'apprécie le forum de Fairphone : https://forum.fairphone.com/.

J'ai un collègue qui utilise Terragrunt (https://terragrunt.gruntwork.io/).
Je pense que j'ai déjà croisé cet outil mais sans trop y prêter attention.

Pour le moment, je ne comprends pas très bien l'intérêt de Terragrunt, j'ai l'impression que c'est un wrapper au-dessus de Terraform ou OpenTofu.

#JaimeraisUnJour prendre le temps de faire un POC de Terragrunt.

#JaiDécouvert Cloud Pi Native (https://github.com/cloud-pi-native)

#JaiDécouvert l'extension GNOME Shell : astra-monitor (from).

J'ai bien aimé le contenu de la page "Project Comparison". Par exemple, ce paragraphe :

Introduction

Secondly, it acts as a guide for users, offering greater insights and assisting them in making an informed decision when choosing the ideal tool for their needs. By highlighting the unique features, performance benchmarks, and key differences between Astra Monitor and its alternatives, we hope to foster a transparent and informative environment for both our development team and the user community at large.

source

Voici en screenshot le résultat de mon installation :

Dépendances que j'ai installées sous ma Fedora Workstation (commit dans mon repository dotfiles) :

$ sudo dnf install \
    libgtop2-devel \
    nethogs \
    iotop \
    libdrm-devel \
    https://github.com/Umio-Yasuno/amdgpu_top/releases/download/v0.10.4/amdgpu_top-0.10.4-1.x86_64.rpm

#JaiDécouvert https://github.com/Umio-Yasuno/amdgpu_top

Voici ce que retourne la commande sensors sur mon laptop :

$ sensors
thinkpad-isa-0000
Adapter: ISA adapter
fan1:        65535 RPM
CPU:          +63.0°C
GPU:              N/A
temp3:        +63.0°C
temp4:         +0.0°C
temp5:        +63.0°C
temp6:        +63.0°C
temp7:        +63.0°C
temp8:         +0.0°C

amdgpu-pci-3300
Adapter: PCI adapter
vddgfx:        1.45 V
vddnb:       734.00 mV
edge:         +51.0°C
PPT:          19.18 W

BAT0-acpi-0
Adapter: ACPI interface
in0:          15.14 V
power1:       11.96 W

ath11k_hwmon-pci-0100
Adapter: PCI adapter
temp1:        +41.0°C

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +62.9°C

nvme-pci-0200
Adapter: PCI adapter
Composite:    +33.9°C  (low  = -273.1°C, high = +80.8°C)
                       (crit = +84.8°C)
Sensor 1:     +33.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +45.9°C  (low  = -273.1°C, high = +65261.8°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +63.0°C
temp2:        +20.0°C

Voici comment j'ai configuré la température du haut (45°C) et du bas (44°C) du screenshot :

• En haut, j'ai sélectionné le paramètre acpitz-acpi-0/temp1 qui contient la température du CPU
• En bas, j'ai sélectionné le paramètre amdgpu-pci-3300/edge qui contient la température du GPU

Voici mon fichier de configuration pour astra-monitor astra-monitor-settings.json.
Il est possible de facilement l'importer dans la section "Utility" de astra-monitor.

Je viens de créer la page "Mes sacs".

Cela fait des années que je m'intéresse au sujet des solutions de sauvegarde en continu de bases de données PostgreSQL.

Dans cette note, le terme "sauvegarde en continu" ne signifie pas Point In Time Recovery.

Jusqu'à présent, je me suis toujours concentré sur la méthode "mainstream", qui consiste principalement à effectuer un backup binaire couplé avec une sauvegarde continue du WAL. Par exemple des solutions basées sur pg_basebackup, pgBackRest ou barman.

Une autre solution consiste à déployer une seconde instance PostgreSQL en mode streaming replication.

Une troisième solution que #JaimeraisUnJour tester : mettre en place une sauvegarde incrémentale basée sur le filesystème btrfs.
Plus précisément, la commande btrfs-send. La documentation de Dalibo mentionne cette méthode de sauvegarde.

Samedi dernier, j'ai imaginé une autre méthode qui me plait beaucoup par sa relative flexibilité et sa simplicité.

Elle consisterait à sauvegarder des tables de manière granulaire à intervalle de temps régulier vers un Object Storage à l'aide d'un Foreign Data Wrapper.
Pour cela, j'ai identifié parquet_s3_fdw, basé sur le format Apache Parquet qui permet de lire et d'écrire des données sur un bucket Object Storage.

Features

• Support SELECT of parquet file on local file system or Amazon S3.
• Support INSERT, DELETE, UPDATE (Foreign modification).
• Support MinIO access instead of Amazon S3.

source

J'ai utilisé de nombreuses fois Foreign Data Wrapper pour copier de manière granulaire des données entre deux bases de données PostgreSQL.

J'ai trouvé cette méthode très pratique, en particulier la possibilité de pouvoir utiliser un "pattern" SQL de copie du type :

INSERT INTO clients_local (id, nom, email, date_derniere_maj)
SELECT 
    d.client_id, 
    d.nom_client, 
    d.email_client,
    CURRENT_TIMESTAMP
FROM 
    distant.clients_distant d
WHERE 
    d.date_modification > (SELECT MAX(date_derniere_maj) FROM clients_local)
ON CONFLICT (id) DO UPDATE 
SET 
    nom = EXCLUDED.nom,
    email = EXCLUDED.email,
    date_derniere_maj = EXCLUDED.date_derniere_maj;

#JaimeraisUnJour réaliser un POC de cette idée basée sur parquet_s3_fdw.

Il existe deux familles de méthodes de backup d'une base de données PostgreSQL :

• Backup logique
• Backup binaire à "chaud et à froid"

Voici une présentation simplifiée des différences entre ces deux modes de sauvegarde, qui peut comporter certaines imprécisions dues à cette vulgarisation.

Un backup logique est effectué par pg_dump sur une instance PostgreSQL en cours d'exécution (nommée "à chaud"). pg_dump supporte plusieurs formats d'archivage dont plain et custom.

Le format plain génère un fichier SQL classique, lisible "humainement".
Le format custom génère un fichier binaire, qui est plus flexible et a une taille bien plus réduite que le format plain. Il est toujours possible de générer un fichier SQL comme plain à partir d'un fichier custom : avec la commande pg_restore -f output.sql fichier_custom.

Il est possible de réaliser des sauvegardes et restaurations à "distance", via le protocole classique PostgreSQL Frontend Backend Protocol.
Il est possible d'importer un backup logique vers une instance PostgreSQL de version différente, en général plus récente.

Un backup binaire peut être effectué à "chaud" ou à "froid". En simplifiant, cela consiste à sauvegarder les fichiers PostgreSQL du filesystem et optionnellement sauvegarder aussi les journaux (WAL) de PostgreSQL. Pour effectuer un backup binaire, il existe la commande officielle pg_basebackup, mais aussi d'autres solutions plus complètes, comme pgBackRest ou barman.

Les systèmes de backup binaire de PostgreSQL ont l'avantage de pouvoir restaurer une sauvegarde à un point précis dans le temps (fonctionnalité PITR).

Je constate que la mise en place d'un backup binaire est plus complexe à mettre en place qu'un backup logique.

Voici mon POC le plus avancé concernant les backup binaire : poc-pg_basebackup_incremental.

Actuellement, pour sauvegarder des instances PostgreSQL, j'utilise pg_back-docker-sidecar qui est une solution de backup logique, basé sur pg_back, déployé sous la forme d'un Docker sidecar.

J'envisage aussi d'expérimenter une méthode basée sur parquet_s3_fdw que j'ai décrite dans 2025-04-18_1140.

Pour des informations plus approfondies à propos de ces sujets, je vous conseille la documentation de ces formations de Dalibo :

• Sauvegarde et restauration
• Point In Time Recovery
• Outils de sauvegarde physique
• Gestion d’un sinistre

Alexandre m'a partagé le projet Postgres Operator, que j'avais peut-être croisé par le passé, mais que j'avais oublié.

Postgres Operator permet entre autres de déployer des instances PostgreSQL dans un cluster Kubernetes mais aussi de mettre en place des systèmes de backup logique et backup binaire.

Je viens de signer pour une mission de prestation de développeur Freelance de 6 mois sur le projet Albert Conversation chez la DINUM.

Mon objectif est de mettre mes compétences au service de différents projets DINUM / beta.gouv.fr sur le long terme, là où elles seront le plus utiles pour les services publics numériques.

Je viens de terminer une première itération de travail sur Projet 27 - "Créer un POC de pg_back".

Le résultat se trouve dans le repository GitHub : pg_back-docker-sidecar

J'ai passé en tout 17 h 30 sur ce projet, écriture de notes incluse.

Ce projet a évolué par rapport à mon objectif initial :

Initialement, dans ce dépôt, je voulais tester l'implémentation de pg_back déployé dans un conteneur Docker comme un « sidecar » pour sauvegarder une base de données PostgreSQL déployée via Docker.

Et progressivement, j'ai changé l'objectif de ce projet. Il contient maintenant

• le code source pour construire une image Docker Sidecar nommée stephaneklein/pg_back-docker-sidecar:2.5.0-delete-local-file-after-upload
• un tutoriel étape par étape qui présente tous les aspects de l'utilisation de ce conteneur
• un espace de travail qui me permet de contribuer au projet pg_back en amont : ./src/

source

Voici tous les éléments testés dans le tutoriel :

• pg_back est dépolyé dans un Docker sidecar
• L'instance PostgreSQL est sauvegardée dans une instance Minio
• Les archives sont chiffrées avec age
• Les archives sont générées au format custom
• J'ai documenté une méthode pour télécharger une archive dans un dossier du workspace du développeur
• J'ai documenté une méthode pour restaurer l'archive dans un serveur PostgreSQL déployé via Docker
• J'ai testé le fonctionnement du système d'expiration des archives
• J'ai testé la fonctionnalité de "purge" automatique

Éléments que j'ai implémentés

L'image Docker proposée par pg_back ne contient pas de scheduler de type cron et ne suit pas les recommandations The Twelve-Factors App.

J'ai décidé d'implémenter ma propre image Docker stephaneklein/pg_back-docker-sidecar:2.5.0-delete-local-file-after-upload avec les ajouts suivants :

• Support de configuration basé sur des variables d'environnement, par exemple :

  pg_back:
    image: stephaneklein/pg_back-docker-sidecar:2.5.0-delete-local-file-after-upload
    environment:
      POSTGRES_HOST: postgres1
      POSTGRES_PORT: 5432
      POSTGRES_USER: postgres
      POSTGRES_DBNAME: postgres
      POSTGRES_PASSWORD: password
      
      BACKUP_CRON: ${BACKUP_CRON:-0 3 * * *}
      UPLOAD: "s3"
      UPLOAD_PREFIX: "foobar"
      ...

• Intégration de Supercronic pour exécuter pg_back régulièrement, une fonctionnalité de type cron

Patch envoyé en upstream

J'ai proposé deux patchs à pg_back :

• Add upload_prefix option to pg_back.conf example file
• Add the --delete-local-file-after-upload to delete local file after upload

Le premier patch est totalement mineur.

Dans la version actuelle 2.5.0 de pg_back, les archives dump ne sont pas supprimées du filesystem de container après l'upload vers l'Object Storage.
Ce choix me perturbe, car je préfère éviter de surcharger le disque avec des fichiers d'archives volumineux qui risquent de saturer l'espace disponible.

Pour éviter cela, j'ai implémenté "Add the --delete-local-file-after-upload to delete local file after upload" qui permet de supprimer les fichiers intermédiaires après upload.

Bilan

J'ai réussi à effectuer un cycle complet de la sauvegarde à la restauration.
J'ai décidé d'utiliser pg_back pour mes sauvegardes PostgreSQL automatique vers Object Storage.

J'ai déprécié le projet restic-pg_dump-docker pour inviter à utiliser pg_back.

Idée d'amélioration

#JaimeraisUnJour créer et implémenter les issues suivantes.

1. Implémenter une commande pg_back snapshots pour lister les snapshots sous une forme facilement lisible par un humain. Actuellement, le retour de la commande ressemble à ceci :

$ pg_back --list-remote s3
foobar/hba_file_2025-04-14T14:58:08Z.out.age
foobar/hba_file_2025-04-14T14:58:39Z.out.age
foobar/ident_file_2025-04-14T14:58:08Z.out.age
foobar/ident_file_2025-04-14T14:58:39Z.out.age
foobar/pg_globals_2025-04-14T14:58:08Z.sql.age
foobar/pg_globals_2025-04-14T14:58:39Z.sql.age
foobar/pg_settings_2025-04-14T14:58:08Z.out.age
foobar/pg_settings_2025-04-14T14:58:39Z.out.age
foobar/postgres_2025-04-14T14:58:08Z.dump.age
foobar/postgres_2025-04-14T14:58:39Z.dump.age

Je ne trouve pas ce rendu agréable à lire. J'aimerais afficher quelque chose qui ressemble à la sortie de restic. Par exemple :

$ pg_back snapshots
ID        Date                 Folder
---------------------------------------
40dc1520  2025-04-14 14:58:08  foobar
79766175  2025-04-14 14:58:39  foobar

2. Implémenter un système de suppressions des archives basé sur des règles plus avancées, comme celle de restic

3. Implémenter un refactoring vers cobra pour utiliser des sous-commandes (subcommands) et éviter le mélange entre paramètres et commandes.

À ce jour, je n'ai pas trouvé de repository Mise ou Asdf pour installer les "Client Applications" de PostgreSQL, par exemple : psql, pg_dump, pg_restore.

Il existe asdf-postgres, mais ce projet me pose quelques problèmes :

• L'installation basée sur le code source de PostgreSQL avec une phase de compilation qui peut être longue et consommer beaucoup d'espace disque.
• L'intégralité de PostgreSQL est installée alors que je n'ai besoin que des "Client Applications".

#JaimeraisUnJour créer une repository Mise ou Asdf qui permet d'installer les "Client Applications" en mode binaire. Pour le moment, je n'ai aucune idée sur quels binaires me baser 🤔.

En attendant de créer ou de trouver ce repository, voici ci-dessous mes méthodes actuelles d'installation des "PostgreSQL Client Applications".

Sous MacOS

Sous MacOS, j'utilise Brew pour installer le package libpq qui contient les "PostgreSQL Client Applications".

$ brew install libpq

ou alors pour l'installation d'une version spécifique :

$ brew install libpq@17.4

Sous Fedora

Sous Fedora, j'installe le package PostgreSQL client proposé sur la page "Downloads" officielle de PostgreSQL.
Cette méthode me permet d'installer précisément une version majeure précise de PostgreSQL :

source

Voici les instructions pour installer la dernière version de PostgreSQL 17 sous Fedora 41 :

$ sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/F-41-x86_64/pgdg-fedora-repo-latest.noarch.rpm
$ sudo rpm --import https://download.postgresql.org/pub/repos/yum/keys/PGDG-RPM-GPG-KEY-Fedora
$ sudo dnf update -y

Le package nommé postgresql17 contient uniquement les "PostgreSQL Client Applications" :

$ dnf info postgresql17
Mise à jour et chargement des dépôts :
Dépôts chargés.
Paquets installés
Nom                      : postgresql17
Epoch                    : 0
Version                  : 17.4
Version                  : 1PGDG.f41
Architecture             : x86_64
Taille une fois installé : 10.7 MiB
Source                   : postgresql17-17.4-1PGDG.f41.src.rpm
Dépôt d'origine          : pgdg17
Résumé                   : PostgreSQL client programs and libraries
URL                      : https://www.postgresql.org/
Licence                  : PostgreSQL
Description              : PostgreSQL is an advanced Object-Relational database management system (DBMS).
                         : The base postgresql package contains the client programs that you'll need to
                         : access a PostgreSQL DBMS server. These client programs can be located on the
                         : same machine as the PostgreSQL server, or on a remote machine that accesses a
                         : PostgreSQL server over a network connection. The PostgreSQL server can be found
                         : in the postgresql17-server sub-package.
                         :
                         : If you want to manipulate a PostgreSQL database on a local or remote PostgreSQL
                         : server, you need this package. You also need to install this package
                         : if you're installing the postgresql17-server package.
Fournisseur              : PostgreSQL Global Development Group
$ dnf repoquery -l postgresql17 | grep "/bin"
Mise à jour et chargement des dépôts :
Dépôts chargés.
/usr/pgsql-17/bin/clusterdb
/usr/pgsql-17/bin/createdb
/usr/pgsql-17/bin/createuser
/usr/pgsql-17/bin/dropdb
/usr/pgsql-17/bin/dropuser
/usr/pgsql-17/bin/pg_basebackup
/usr/pgsql-17/bin/pg_combinebackup
/usr/pgsql-17/bin/pg_config
/usr/pgsql-17/bin/pg_createsubscriber
/usr/pgsql-17/bin/pg_dump
/usr/pgsql-17/bin/pg_dumpall
/usr/pgsql-17/bin/pg_isready
/usr/pgsql-17/bin/pg_receivewal
/usr/pgsql-17/bin/pg_restore
/usr/pgsql-17/bin/pg_waldump
/usr/pgsql-17/bin/pg_walsummary
/usr/pgsql-17/bin/pgbench
/usr/pgsql-17/bin/psql
/usr/pgsql-17/bin/reindexdb
/usr/pgsql-17/bin/vacuumdb

Installation de ce package :

$ sudo dnf install postgresql17
$ psql --version
psql (PostgreSQL) 17.4

Suite à 2025-04-10_2034, je viens de créer le Projet 27 - "Créer un POC de pg_back".

Dans la documentation de restic, #JaiDécouvert resticprofile :

Scheduling backups

Restic does not have a built-in way of scheduling backups, as it’s a tool that runs when executed rather than a daemon. There are plenty of different ways to schedule backup runs on various different platforms, e.g. systemd and cron on Linux/BSD and Task Scheduler in Windows, depending on one’s needs and requirements. If you don’t want to implement your own scheduling, you can use resticprofile.

source

Le projet resticprofile a commencé en 2019, tout comme restic, il est écrit en Golang.

resticprofile permet de lancer restic à partir d'un fichier de configuration. D'après l'extrait ci-dessous, l'équipe de restic ne semble pas vouloir intégrer un système de fichiers de configuration.

Configuration profiles manager for restic backup

resticprofile is the missing link between a configuration file and restic backup. Creating a configuration file for restic has been discussed before, but seems to be a very low priority right now.

source

Je me relance sur mes sujets de backup de PostgreSQL.

Au mois de février dernier, j'ai initié le « Projet 23 - "Ajouter le support pg_basebackup incremental à restic-pg_dump-docker" ».

J'ai ensuite publié les notes suivantes à ce sujet :

• 2025-02-09_1705
• 2025-02-12_1044
• 2025-02-12_1511
• 2025-02-12_2305
• 2025-02-13_1409

À ce jour, je n'ai pas fini mes POC suivants :

• poc-pgbackrest
• poc-barman
• poc-pg_basebackup_incremental

poc-pg_basebackup_incremental est la seule méthode que j'ai réussi à faire fonctionner totalement.

#JaimeraisUnJour terminer ces POC.

Aujourd'hui, je m'interroge sur les motivations qui m'ont conduit en 2020 à intégrer restic dans mon projet restic-pg_dump-docker. Avec le recul, l'utilisation de cet outil pour la simple sauvegarde d'archives pg_dump me semble désormais moins évidente qu'à l'époque.

J'ai fait ce choix peut-être pour bénéficier directement du support des fonctionnalités suivantes :

• Uploader vers différents Object Storage : S3-compatible Storage
• Le système de rétention : Removing snapshots according to a policy
• Le chiffrement : Encryption
• Et naïvement, je pensais peut-être pouvoir utiliser le système de déduplication des données : Backups and Deduplication

Après réflexion, je pense que pour la sauvegarde d'archives pg_dump, les fonctionnalités de déduplication et de sauvegarde incrémentale offertes par restic génèrent en réalité une surconsommation d'espace disque et de ressources CPU sans apporter aucun bénéfice.

J'ai ensuite effectué quelques recherches pour savoir s'il existait un système de sauvegarde PostgreSQL basé sur pg_dump et un système d'upload vers Object Storage et #JaiDécouvert pg_back (https://github.com/orgrim/pg_back/).

En 2020, quand j'ai créé restic-pg_dump-docker, je pense que je n'avais pas retenu pg_back car celui-ci était minimaliste et ne supportait pas encore l'upload vers de l'Object Storage.

En 2025, pg_back supporte toutes les fonctionnalités dont j'ai besoin :

pg_back is a dump tool for PostgreSQL. The goal is to dump all or some databases with globals at once in the format you want, because a simple call to pg_dumpall only dumps databases in the plain SQL format.

Behind the scene, pg_back uses pg_dumpall to dump roles and tablespaces definitions, pg_dump to dump all or each selected database to a separate file in the custom format. ...

Features

• ...
• Choose the format of the dump for each database
• ...
• Dump databases concurrently
• ...
• Purge based on age and number of dumps to keep
• Dump from a hot standby by pausing replication replay
• Encrypt and decrypt dumps and other files
• Upload and download dumps to S3, GCS, Azure, B2 or a remote host with SFTP

source

Je souhaite :

• Créer et publier un playground pour tester pg_back
• Si le résultat est positif, alors je souhaite ajouter une note en introduction de restic-pg_dump-docker pour inviter à ne pas utiliser ce projet et renvoyer les lecteurs vers le projet pg_back.

#JaiDécouvert ici la fonctionnalité "Incremental Static Regeneration (ISR)" de NextJS.

L'Incremental Static Regeneration (ISR) est un mélange de génération static et de régénération dynamique.

Lors du build du site toutes les pages sont générées de manière statique. Cependant, certaines peuvent être "marquées" : ces pages clairement identifiées seront régénérées à intervalle régulier après le déploiement du site, faisant appel à des API ou une base de données pour garder la donnée à jour.

Lors de la visite d'une page à régénérer, une version "ancienne" de la page s'affiche, mais une demande de régénération est envoyée au serveur. La page est ainsi régénérée et renvoyée instantanément au visiteur, et prête à être affichée au visiteur suivant. Le cycle peut alors recommencer.

source

J'ai aussi lu cette page de documentation de Vercel :

Incremental Static Regeneration (ISR) allows you to create or update content on your site without redeploying. ISR's main benefits for developers include:

• Better Performance: Static pages can be consistently fast because ISR allows Vercel to cache generated pages in every region on our global Edge Network and persist files into durable storage
• Reduced Backend Load: ISR helps reduce backend load by using cached content to make fewer requests to your data sources
• Faster Builds: Pages can be generated when requested by a visitor or through an API instead of during the build, speeding up build times as your application grows

ISR is available to applications built with:

• Next.js
• SvelteKit
• Nuxt
• Astro
• Gatsby
• Or any custom framework solution that implements the Build Output API

source

J'ai étudié le support ISR de SvelteKit. Il semble que cette fonctionnalité soit supportée uniquement par l'adapter-vercel.
J'ai identifié l'issue suivante : Would revalidating a static page work when self-hosted?.

#JaimeraisUnJour prendre le temps de creuser plus en profondeur ce sujet.

Un collègue m'a fait découvrir Trapeze (https://trapeze.dev/).

Trapeze is a mobile project configuration toolbox for native iOS and Android project management. From a simple YAML format, Trapeze makes it easy to automate the configuration of native mobile iOS and Android projects, and supports traditional native, Ionic, Capacitor, React Native, Flutter, and .NET MAUI. The long-term goal of Trapeze is to enable fully immutable native mobile projects.

Trapeze works by automating the modification of pbxproj, plist, XML, Gradle, JSON, resource, properties, and other files in iOS and Android app projects. It features a configuration-driven tool that takes a YAML file with iOS and Android project modifications and performs those modifications from the command line interactively.

source

C'est un projet créé par l'équipe Ionic, créatrice de Capacitor.

Je ne comprends pas comment j'ai pu passer à côté de cet outil qui est pourtant mentionné dans la documentation officielle de Capacitor 🙈 !

Both projects and their documentation are available in the Trapeze repo.

source

J'ai parcouru un peu la documentation et je trouve cet outil excellent !
C'est tout à fait ce dont j'avais besoin dans mon dans "Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor" !

Je pense que cet outil me permet d'éliminer tous mes "hacks" pérésents dans le repository : poc-capacitor.

#JaimeraisUnJour prendre le temps d'intégrer Trapeze à poc-capacitor.

En 2024, j'ai utilisé avec succès dans un projet client la librairie svelte-splitpanes.

A predictable responsive component to layout resizable view panels supporting an multitude of advanced features (min/max bounderies, snap, expand on double click, fixed size, rtl).

source

Le projet svelte-splitpanes a débuté en avril 2022.

Aujourd'hui, en étudiant les projets de Hunter Johnston, #JaiDécouvert une autre librairie de gestion de "pane", nommée PaneForge, qui a débuté en février 2024.
Cette librairie n'existait pas au moment où j'ai sélectionné svelte-splitpanes.

Pour le moment, je n'ai aucune idée de la motivation de Hunter Johnston d'avoir créé PaneForge plutôt qu'utiliser la librairie existante svelte-splitpanes.

Pour le moment, je n'ai pas compris pourquoi Hunter Johnston a décidé de créer PaneForge plutôt qu'utiliser la bibliothèque existante svelte-splitpanes 🤔.

Je viens de créer cette issue : "Suggestion: add an explanation of the differences between PaneForge and svelte-splitpane at the end of the README".

Note de type #mémento #mémo.

J'ai souvent besoin d'exécuter l'équivalent de :

$ scp -r root@myserver:/foo/bar/ ./tmp/

ou l'inverse :

$ scp -r ./tmp/ root@myserver:/foo/bar/

sur des serveurs sur lesquels je n'ai pas directement accès à l'utilisateur root par ssh.

J'accède, par exemple, à ce serveur via l'utilisateur ubuntu. L'utilisateur ubuntu n'a pas accès aux fichiers que je souhaite download ou upload.

Sur le serveur, j'ai accès aux fichiers de l'utilisateur root via sudo.

Voici une astuce pour download des fichiers via ssh et sudo :

$ ssh ubuntu@myserver "sudo tar cf - -C /foo/bar/ ." | tar xf - -C ./tmp/

Et, voici une méthode pour upload :

$ tar cf - -C ./tmp/ . | ssh ubuntu@myserver "sudo tar xf - -C /foo/bar/"

Pour un projet, je dois mettre en place un système de sauvegarde sécurisé (WORM).
Ici, "sécurisé" signifie :

• qui empêche la suppression accidentelle ou intentionnelle des données ;
• une protection contre les ransomwares.

Pour cela, j'ai décidé de sauvegarder ces données chez deux fournisseurs d'Object Storage :

• Scaleway Object Storage
• Backblaze

Je viens de publier le playground append-only-backup-playground qui m'a permis de tester la configuration de bucket Backblaze et Scaleway.

Object Storage append-only backup playground

In this "playground" repository, I explore different methods to configure object storage services in append-only or write-once-read-many (WORM) mode.

source

J'ai testé deux méthodes qui interdisent la suppression des données :

• 1. La première, basée sur une clé d'accès avec des droits limités : l'interdiction de supprimer des fichiers. Si un attaquant parvient à s'infiltrer sur un serveur qui effectue des sauvegardes, la clé ne lui permettra pas d'effacer les anciennes sauvegardes.
• 2. La seconde méthode plus stricte utilise la fonctionnalité object lock en mode GOVERNANCE ou COMPLIANCE.

Je vous recommande d'être vigilant avec le mode COMPLIANCE, car il vous sera impossible de supprimer les fichiers avant leur date de rétention, sauf si vous décidez de supprimer entièrement votre compte client !

Personnellement, je recommande d'utiliser la méthode 1 pour tous les environnements de développement.
En général, je pense que la méthode 1 est suffisante, même pour les environnements de production. Mais si les données sont vraiment critiques, alors je conseille le mode GOVERNANCE ou COMPLIANCE.

Le repository append-only-backup-playground contient 4 playgrounds :

• Pour tester la méthode 1 :
  • /scaleway/ : configuration d'un bucket Scaleway Object Storage et une clé qui ne peut pas supprimer de fichier. L'option de versionning est activée.
  • /backblaze/ : configuration d'un bucket Backblaze et une clé qui ne peut pas supprimer de fichier. L'option de versionning est activée.
• Pour tester la méthode 2 :
  • /scaleway-object-lock/ : la même chose que /scaleway/ avec en plus la configuration de object lock en mode GOVERNANCE avec une durée de rétention définie à 1 jour.
  • /backblaze-object-lock/ : la même chose que /backblaze/ avec en plus la configuration de object lock en mode GOVERNANCE avec une durée de rétention définie à 1 jour.

Hier, j'ai écouté l'épisode 238 - La fin des ERP libres ? du podcast "Libre à vous".

Dans cet épisode, #JaiDécouvert ce que sont les "Plateforme de Dématérialisation Partenaire" (PDP) et le Portal Public de Facturation (PPF).

L’objectif principal du portail public de facturation était d'offrir un accès à la facturation électronique pour toutes les entreprises françaises. Pour l'État, il s'agissait d'un outil essentiel pour optimiser la généralisation des factures électroniques et ainsi accélérer la transformation digitale des entreprises.

Voici les arguments qui poussaient le gouvernement à mettre en oeuvre cette obligation :

• faciliter la gestion financière des entreprises au quotidien ;
• simplifier les déclarations de TVA ;
• lutter contre la fraude fiscale.

source

Je pense que ce nouveau système va simplifier tout le système de déclaration de TVA, voir la note 2025-02-03_1718 à ce sujet.

C'est peut-être pour cela que l'administration ne corrige pas la "dette fonctionnelle" à ce niveau. Peut-être que les PDP et le PPF va rendre tout cela obsolète 🤔.

Il y a quelques mois, j'avais identifié Amazon Quantum Ledger Database qui pourrait servir pour créer un Consent Management Provider.
Aujourd'hui, #JaiDécouvert le mode de rétention "Compliance" de Scaleway Object Storage.

When this mode is set, an object version cannot be overwritten or deleted by any user. If the Compliance mode is configured for an object, then its retention mode cannot be changed, and its retention period cannot be shortened. In other words, it ensures that an object version cannot be overwritten or deleted for the duration of the retention period. Note

Note : When the compliance mode is enabled, it is only possible to overwrite it or delete an object once the object lock expires or upon deleting your Scaleway account.

source

« La suppression du compte » est une action radicale !

Je pense que cette fonctionnalité est une alternative minimaliste à Amazon Quantum Ledger Database.

Cette fonctionnalité pourrait servir de base pour créer un Plateforme de Dématérialisation Partenaire pour Dolibarr ou tout autre logiciel libre de facturation 🤔.

Voici quelques principes qui me guident. Je pense qu'ils contribuent à rendre une organisation efficace et efficiente.

1. La loi empirique de Gall :

« Un système complexe qui fonctionne se trouve invariablement avoir évolué depuis un système simple qui fonctionnait.
La proposition inverse se révèle également exacte : Un système complexe développé de A à Z ne fonctionne jamais et vous n'arriverez jamais à le faire fonctionner. Vous devez recommencer depuis le début, en commençant par un système simple. »

source

2. Je suis convaincu de la pertinence du modèle de Tuckman pour comprendre comment les équipes se construisent et évoluent au fil du temps. En conséquence, je crois qu'une organisation doit accorder suffisamment de temps aux équipes pour qu'elles atteignent leur phase de performance, puis veiller à maintenir la composition de l'équipe sur la durée.

3. Le modèle du triangle de gestion de projet qui je trouve est très bien expliqué dans le livre Getting Real :

Voici un moyen simple de lancer le projet dans les délais et le budget impartis : ne pas les modifier. Il ne faut jamais consacrer plus de temps ou d'argent à un problème, mais simplement en réduire la taille (le périmètre).

Il existe un mythe qui dit que l'on peut lancer un projet dans les délais, en respectant le budget et le champ d'application. Cela n'arrive presque jamais et, lorsque c'est le cas, la qualité s'en ressent souvent.

Si vous ne pouvez pas tout faire tenir dans le temps et le budget impartis, n'augmentez pas le temps et le budget. Au contraire, réduisez le champ d'application. Il sera toujours temps d'ajouter des choses plus tard - plus tard est éternel, maintenant est éphémère.

Il vaut mieux lancer quelque chose d'excellent dont la portée est un peu plus réduite que prévu que de lancer quelque chose de médiocre et plein de trous parce qu'il fallait respecter une fenêtre magique de temps, de budget et de portée. Laissez la magie à Houdini. Vous avez une véritable entreprise à gérer et un véritable produit à livrer.

source

Note de type #mémento pour calculer la taille des tables PostgreSQL.

Commande pour calculer la taille de la base de données entière :

postgres=# select pg_size_pretty(pg_database_size('postgres'));
 pg_size_pretty
----------------
 74 GB

Commande pour voir les détails table par table :

SELECT
  nspname                                               AS "schema",
  pg_class.relname                                      AS "table",
  pg_size_pretty(pg_total_relation_size(pg_class.oid))  AS "total_size",
  pg_size_pretty(pg_relation_size(pg_class.oid))        AS "data_size",
  pg_size_pretty(pg_indexes_size(pg_class.oid))         AS "index_size",
  pg_stat_user_tables.n_live_tup                        AS "rows",
  pg_size_pretty(
    pg_total_relation_size(pg_class.oid) /
    (pg_stat_user_tables.n_live_tup + 1)
  )                                                     AS "total_row_size",
  pg_size_pretty(
    pg_relation_size(pg_class.oid) /
    (pg_stat_user_tables.n_live_tup + 1)
  )                                                     AS "row_size"
FROM
  pg_stat_user_tables
JOIN
  pg_class
ON
  pg_stat_user_tables.relid = pg_class.oid
JOIN
  pg_catalog.pg_namespace AS ns
ON
  pg_class.relnamespace = ns.oid
ORDER BY
  pg_total_relation_size(pg_class.oid) DESC;

 schema |      table      | total_size | data_size  | index_size |  rows   | total_row_size |  row_size
--------+-----------------+------------+------------+------------+---------+----------------+------------
 public | table1          | 72 GB      | 1616 MB    | 1039 MB    | 7456403 | 10 kB          | 227 bytes
 public | table2          | 1153 MB    | 754 MB     | 399 MB     | 2747998 | 440 bytes      | 287 bytes
 public | table3          | 370 MB     | 8192 bytes | 47 MB      |       8 | 41 MB          | 910 bytes
 public | table4        | 232 kB     | 136 kB     | 56 kB      |     422 | 561 bytes      | 329 bytes
(7 rows)

Quand j'ai travaillé en décembre 2024 sur mon "Projet 15 - Installation et configuration de OpenWrt sur Xiaomi Mi Router 4A Gigabit", j'avais découvert le projet #hardware OpenWrt One via ces threads Hacker News :

• Janvier 2024 : OpenWrt One/AP-24.XY: new open source router board by OpenWrt and Banana Pi (90 commentaires)
• Novembre 2024 : OpenWrt One (31 commentaires)
• Décembre 2024 : OpenWRT One Released: First Router Designed Specifically for OpenWrt (141 commentaires)
• Décembre 2024 : OpenWrt One router officially launched (43 commentaires)

Today, we at SFC, along with our OpenWrt member project, announce the production release of the OpenWrt One. This is the first wireless Internet router designed and built with your software freedom and right to repair in mind. The OpenWrt One will never be locked down and is forever unbrickable. ...

The OpenWrt One demonstrates what's possible when hardware designers and manufacturers prioritize your software right to repair; OpenWrt One exuberantly follows these requirements of the copyleft licenses of Linux and other GPL'd programs. This device provides the fully copyleft-compliant source code release from the start. Device owners have all the rights as intended on Day 1; device owners are encouraged to take full advantage of these rights to improve and repair the software on their OpenWrt One.

source

J'ai envie de m'en commander un pour remplacer mon Xiaomi Mi Router 4A Gigabit Edition.

Mais, je viens de lire ce commentaire sur LinuxFr :

• La carte mère et le boîtier sont bien larges et pourtant, ils ne sont pas arrivés à caser un disque dur au format courant 2280.
• La puce WiFi est soudée => impossible à faire évoluer. Il y'a déjà du wifi 7
• Le pilote de cette puce est un vieux blob binaire à mon avis. Il n'y a rien ici en tout cas: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/mediatek?h=for-next
• Si je devais investir dans un équipement de ce genre, j'en prendrai un qui fait aussi le réseau cellulaire.
• Je ne comprends pas trop l'intérêt d'avoir un port Ethernet à 1Gb et l'autre ) 2,5Gb
• Au final, cela fait presque dans les 120€

Je pense que j'irais plutôt vers un truc dans ce genre (plus cher mais plus polyvalent):
https://www.aliexpress.com/item/1005004360072281.html

source

« Topton nouveau ordinateur pare-feu Intel N150 N100 N5105 N5100 routeur souple 4x2.5G i226 LAN Mini PC industriel sans ventilateur pfSense PVE ESXi avec 4GB Ram et 128 GB NVMe » à 156 €.

J'ai lu cet autre commentaire qui préfère le modèle GL.iNet GL-MT6000 (à 146 €) à OpenWrt One 🤔.

En rédigeant la note 2025-03-20_1020, #JaiDécouvert ici la Licence Publique de l'Union Européenne (EUPL) :

Afin de simplifier ce partage, la Commission a mis sur pied la licence publique de l’Union européenne; elle est disponible en vingt-trois langues officielles de l’Union et est compatible avec de nombreuses licences open source.

page 2

Article Wikipedia de la licence : https://fr.wikipedia.org/wiki/Licence_publique_de_l'Union_européenne

En rédigeant la note 2025-03-20_1020, #JaiDécouvert ici le projet openDesk.

Flexible Teamwork for the Public Sector

openDesk is the customisable office and collaboration suite designed specifically for your needs in public administration.

source

Au 20 mars 2025, voici la liste des composants de openDesk :

Function	Functional Component	Component Version	Upstream Documentation
Chat & collaboration	Element ft. Nordeck widgets	1.11.89	For the most recent release
Collaborative notes	Docs	2.4.0	Online documentation/welcome document available in installed application
Diagram editor	CryptPad ft. diagrams.net	2024.9.0	For the most recent release
File management	Nextcloud	30.0.6	Nextcloud 30
Groupware	OX App Suite	8.35	Online documentation available from within the installed application; Additional resources
Knowledge management	XWiki	16.10.5	For the most recent release
Portal & IAM	Nubus	1.5.1	Univention's documentation website
Project management	OpenProject	15.4.0	For the most recent release
Videoconferencing	Jitsi	2.0.9955	For the most recent release
Weboffice	Collabora	24.04.12.4	Online documentation available from within the installed application; Additional resources
source

En étudiant E/OS, j'ai découvert Murena (https://murena.com/fr/) :

Nous fournissons des smartphones et un espace de travail en ligne privés, durables et entièrement libres.

source

Notre gamme de produits se base sur des logiciels libres, notamment le système d'exploitation déGooglisé E/OS et NextCloud.

source

Je vois Fairphone dans la section "Nos partenaires". Je suppose que les smartphones vendus par Murena sont des Fairphone.

Je lis ici que Murena prend 3% de commission sur la vente des smartphones.

Je remarque que le fondateur et CEO de Murena est Gaël Duval, fondateur de Mandriva Linux.

Le dimanche 17 novembre 2024, j'ai signé la pétition "nº 0729/2024, présentée par N. W., de nationalité autrichienne, sur le déploiement d’un système d’exploitation «UE-Linux» dans les administrations publiques de tous les États membres".

La commission des pétitions du Parlement européen a communiqué sa réponse le 10 janvier 2025 : PETI-CM-767965_FR.pdf .

Quelques extraits :

Le pétitionnaire demande à l’Union de développer un système d’exploitation pour ordinateur sous Linux, appelé «EU-Linux», et de le déployer dans tous les services publics des États membres.
Cette initiative vise à réduire la dépendance à l’égard des produits Microsoft, à garantir le respect du règlement général sur la protection des données et à favoriser la transparence, la durabilité et la souveraineté technologique au sein de l’Union.
Le pétitionnaire insiste sur l’importance de recourir à des solutions open source se substituant à Microsoft 365, telles que Libre Office et Nextcloud, et propose d’adopter le système d’exploitation mobile E/OS sur les appareils utilisés par les pouvoirs publics. Il souligne par ailleurs le potentiel de création d’emplois dans le secteur des technologies de l’information.

page 1

Bon résumé 👍️.

L’Union soutient toujours davantage la création de logiciels open source, qui limitent la dépendance à l’égard de fournisseurs uniques, favorisent la transparence et renforcent la sécurité des données. Récemment, le règlement pour une Europe interopérable, entré en vigueur en avril 2024 afin de favoriser une coopération fluide entre les États membres, a fait du recours à l’open source et aux normes ouvertes dans les services publics une priorité; les administrations sont ainsi plus transparentes, sûres et à l’abri de tout enfermement propriétaire.

page 2

Lien vers le texte du règlement : "Règlement (UE) 2024/903 du Parlement européen et du Conseil du 13 mars 2024 établissant des mesures destinées à assurer un niveau élevé d’interopérabilité du secteur public dans l’ensemble de l’Union (règlement pour une Europe interopérable)".

#UnJourPeuxÊtre je lirais ce règlement qui, après un parcours rapide de son contenu, me semble très intéressant.

a Commission continue de soutenir une transformation numérique de l’Union fondée sur des solutions open source, en établissant des programmes tels que le programme pour une Europe numérique, le CEF Telecom, et l’ancien programme d’interopérabilité ISA². De plus, son programme de financement Horizon Europe subventionne de nombreux projets qui ont trait au développement et à l’utilisation de logiciels et de matériel open source. Enfin, son initiative sur l’internet de nouvelle génération a permis d’investir plus de 140 millions d’EUR dans plus d’un millier de projets participatifs open source.

page 2

Dans cet extrait, #JaiDécouvert :

• Le programme pour une Europe numérique
• CEF Telecom
  • J'ai suivi des liens et j'ai constaté qu'il est possible de consulter les projets financés. Par exemple, 200 000 € sont allés à DINUM pour un travail sur France Connect : Setting up, integration with “France Connect” and implementation of eID
• ISA² - Interoperability solutions for public administrations, businesses and citizens
• Horizon Europe
  • En lisant cette présentation en français, je constate que le soutien aux free software est indirect et secondaire.
• NGI Innovations - qui finance en partie des projets NLNET, qui finance précisément des free software.

La Commission surveille également l’adoption de l’open source par les services publics de l’Union. Pendant près de deux décennies, son Observatoire open source a passé au crible des articles, des rapports ainsi que des études de cas témoignant de l’adoption croissante de l’open source à travers l’Union.

page 2

#JaiDécouvert : Open Source Observatory.

Mentionnons notamment les récents efforts des gouvernements nationaux afin de développer et de mettre en œuvre des solutions open source se substituant aux suites collaboratives de logiciels propriétaires, situation largement conforme à la volonté du pétitionnaire.

page 2

#JaiDécouvert ici le projet openDesk.

Le portail «Europe interopérable», hébergeur de l’Observatoire, incite par ailleurs au partage et à la réutilisation de solutions communes, notamment open source, grâce au catalogage de logiciels.

page 2

Le lien est ici. J'ai l'impression que la page contient une liste de documents d'actualités.

Afin de simplifier ce partage, la Commission a mis sur pied la licence publique de l’Union européenne; elle est disponible en vingt-trois langues officielles de l’Union et est compatible avec de nombreuses licences open source.

page 2

#JaiDécouvert la licence EUPL.

La Stratégie logicielle open source de la Commission incite à l’utilisation de l’open source en interne, encourage la collaboration sur le site code.europa.eu et ouvre la voie à des infrastructures numériques plus durables et transparentes. La Commission organise des hackathons et prévoit des primes aux bogues pour tester des solutions open source prometteuses, comme Nextcloud; elle soutient du reste le passage à l’open source dans des domaines clés, ce qui est d’autant plus conforme aux volontés exprimées dans la pétition.

page 2

• Open source software strategy 2020-2023

Je découvre la forge https://code.europa.eu qui semble être limitée à un usage interne. Je suis surpris de ne voir aucun projet public 🤔.

Conclusion

Il n’y a actuellement pas de projet officiel d’établir un «EU-Linux», mais un grand nombre d’initiatives soutiennent activement l’adoption de solutions open source au sein des administrations publiques des États membres. Ces efforts contribuent plus largement aux objectifs européens de transparence, de sécurité et d’indépendance technologique dans le domaine numérique.

page 3

Ce midi, j'ai échangé avec un ami au sujet de ForgeFed (https://forgefed.org/) :

ForgeFed is a federation protocol for software forges and code collaboration tools for the software development lifecycle and ecosystem. This includes repository hosting websites, issue trackers, code review applications, and more.

source

ForgeFed est une extension d'ActivityPub.

Voici la roadmap d'intégration d'implémentation de ForgeFed dans Forgejo : Roadmap for Federation.

Le 20 août 2024, j'ai découvert la coopérative LeBureau.coop.

Je disais :

Dans ma #todo-list :

• Transférer un de mes noms de domaine vers LeBureau.coop pour tester ;
• Acheter des parts pour devenir sociétaire soutien.

source

4 mois plus tard, le 3 janvier 2025, c'est chose faite : pour tester, j'ai transféré un domaine avec extension .xyz via le formulaire de la page https://lebureau.coop/creation-ou-transfert-de-noms-de-domaine/.

Pour le moment, l'expérience est bonne.

Voici ce que j'ai payé par virement :

• Souscription de 1 part sociale : 8 €
• Transfert du domaine en .xyz : 25,42 €
• Total : 33,42 € TTC

Après la réception du virement bancaire, j'ai reçu un e-mail qui ressemble à ceci :

Bonjour

Nous avons bien reçu ton virement pour le transfert de nom de domaine.

Pour avancer sur le transfert, il faut saisir le code d'autorisation de transfert et la zone DNS sur https://lebureau.coop/ventes/edf199....../tech/

Voici quelques éléments de documentation :

• désactiver le verrouillage de transfert : https://docs.gandi.net/fr/noms_domaine/transfert_sortant/transfert_lock.html
• récupérer le code : https://docs.gandi.net/fr/noms_domaine/transfert_sortant/auth_code.html
• récupérer la zone DNS : sur l'interface web de gandi, aller sur la page du domaine, puis sur "enregistrements dns" puis sur "vue avancée", et c'est le contenu de la zone de texte
• désactiver DNSSEC : https://docs.gandi.net/fr/noms_domaine/utilisateurs_avances/dnssec.html?highlight=dnssec#comment-installer-dnssec-sur-votre-nom-de-domaine-avec-livedns

Une fois que la zone a été saisie, nous pourrons faire le changement de serveur DNS pour éviter toute coupure pendant le transfert, une fois que c'est fait, le code d'autorisation servira à lancer le transfert à proprement parler.

Cordialement,
Arthur Vuillard

J'ai ensuite reçu un accès à https://zones.lebureau.coop qui est une instance PowerDNS-Admin qui permet de configurer ses DNS Record du domaine.

Pour le moment, les demandes de changement de serveurs DNS doivent se faire par e-mail.

Lors de ce transfert, j'ai reçu des e-mails du registrar BookMyName.

Cette situation est tout à fait normale. Comme expliqué dans la vidéo "Les noms de domaine pour se réapproprier Internet", la stratégie de LeBureau.coop est d'être revendeur (BookMyName pour les .xyz) de nom de domaine en attendant de générer suffisamment de revenus pour financer l'obtention d'accréditations directes auprès des différents registres (AFNIC, DotCoop, ICANN...).

Les échanges par e-mail avec Arthur Vuillard ont été à la fois rapide et précis 👌.

D'après la vidéo "Les noms de domaine pour se réapproprier Internet", en juin 2024, LeBureau.coop déclarait avoir 300 clients, 60 sociétaires et 65 000 € de financement.

J'aimerais bien savoir où en est le projet en mars 2025 🤔.

Certaines personnes vont me poser les questions suivantes « Pourquoi tu te compliques la vie avec LeBureau.coop ? Pourquoi ne pas acheter simplement tes domaines directement chez BookMyName ? ».

Ma réponse est la suivante. Depuis quelques années maintenant, je souhaite expérimenter d'autres modèles que le modèle Venture capital, grosses entreprises, etc. En partie à cause du phénomène "De la merdification des choses", comme ce fut, par exemple, le cas avec Gandi.

L'été dernier, j'ai testé social.coop et à présent, c'est au tour de LeBureau.coop.

Cette expérience sera peut-être un échec, mais pour le moment, je n'en sais rien. Je souhaite lui donner sa chance et continuer à explorer d'autres projets de coopératives.

En 2016, Philippe Lafoucrière m'a appris que contrairement aux règles de typographie française, en typographie anglaise, il ne faut pas placer d'espace avant le caractère deux points :.
Je pense d'ailleurs que cette différence est peu connue par les Français et inversement.

Une des conséquences malheureuses de cette différence est la présence généralisée d'une popup de suggestion automatique d'émojis après la séquence <espace>: dans les éditeurs de texte Markdown. Cette fonctionnalité est activée par défaut, sans option pour la désactiver, par exemple, dans GitHub, GitLab ou Discourse.

Exemple :

En 2022, j'ai implémenté et publié un User Styles pour Firefox (maintenant LibreWolf) basé sur Stylus pour désactiver cette autosuggestion automatique d'émojis sur GitHub, GitLab.

Je viens d'ajouter une règle pour Discourse.

Voici ces règles exécutées par Stylus (le fichier) :

@-moz-document regexp("http.*gitlab.*") {
    .atwho-container #at-view-58 {
        display: none !important;
    }
}

@-moz-document domain("github.com") {
    [class^="AutocompleteSuggestions"] {
        display: none !important;
        visibility: hidden !important;
    }
}

@-moz-document regexp(".*discourse.*"), regexp(".*discussion.*") {
    .autocomplete.ac-emoji {
        display: none !important;
    }
}

Comment l'installer ?

• Installer l'extension Firefox : https://add0n.com/stylus.html
• Et ensuite, cliquer sur le lien suivant pour installer mon fichier User Styles : https://github.com/stephane-klein/dotfiles/raw/refs/heads/main/userstyles/disable-gitlab-github-discourse-emoji-picker.user.css

Je vais essayer de rassembler mes User Styles dans ce dossier : https://github.com/stephane-klein/dotfiles/tree/main/userstyles.

Suite à une discusison avec un ami, j'ai les articles Chiffrement homomorphe (https://fr.wikipedia.org/wiki/Chiffrement_homomorphe) et Searchable symmetric encryption (https://en.wikipedia.org/wiki/Searchable_symmetric_encryption).

J'envisage de proposer à ma mère et à ma compagne de se prêter à une expérimentation : une transition en douceur vers des portables sous GNU/Linux, avec mon assistance complète durant tout le processus.

Leur situation actuelle :

• Pour ma compagne : d'un Macbook Air 13" 3ième génération, modèle de 2015, acheté en 2018 à moins de 1000 €, qui tourne bien entendu sous MacOS. Usage principal : navigation web.
• Pour ma maman : un laptop de plus de 10 ans sous MS Windows. Usage principal : Microsoft Word, Microsoft Excel, impression, navigation web.

Choix de la distribution Linux : une Fedora version n-1 (voir la note 2024-01-29 pour plus d'informations sur ce choix).

Plus précisément, j'envisage d'utiliser l'édition Fedora Silverblue, une variante immutable (ou « atomic ») de Fedora Workstation qui propose l'environnement de bureau GNOME.

Je souhaite configurer et rendre très facilement accessibles les applications Signal et RustDesk :

• Signal pour facilement échanger avec moi en cas de difficulté ;
• RustDesk pour me permettre de prendre directement le contrôle du desktop à distance, pour les aider.

Pour ma maman, je souhaite lui faire tester Libre Office. Pour éviter de la perturber avec les formats de fichier, je souhaite configurer Libre Office pour qu'il enregistre par défaut au format de Microsoft Word et Microsoft Excel.

Je souhaite installer quelques extensions GNOME pour que l'environnement Linux ressemble au maximum à MS Windows, par exemple :

• Dash to Dock
• ArcMenu

Je souhaite leur proposer un laptop qui répond aux caractéristiques suivantes :

• si possible à moins de 1000 € ;
• entre 14 et 15 pouces, avec une résolution verticale de 1200 pixels minimum ;
• 16Go de RAM ;
• un trackpad et un châssis avec un maximum de qualité ;
• idéalement convertible en 2 en 1 ou 3 en 1 ;
• silencieux ;
• support GNU/Linux parfait ;

Pour le moment, j'ai identifié les modèles suivants :

• Tuxedo Infinity Flexible 14 - Gen 1 (https://www.tuxedocomputers.com/en/TUXEDO-InfinityFlex-14-Gen1.tuxedo) à 1067 € TTC
• Lenovo Yoga 7 2-in-1 Gen 9 (14" AMD) à 993 € TTC

Je suis actuellement à la recherche de modèles de laptop pour mon "Projet 26", qui répondent aux caractéristiques suivantes :

• si possible à moins de 1000 € ;
• entre 14 et 15 pouces, avec une résolution verticale de 1200 pixels minimum ;
• 16Go de RAM ;
• un trackpad et un châssis avec un maximum de qualité ;
• idéalement convertible en 2 en 1 ou 3 en 1 ;
• silencieux ;
• support GNU/Linux parfait.

Je viens d'effectuer des recherches sur le Subreddit LinuxHardware et je suis tombé sur ce thread "Framework, System76, Tuxedo, Slimbook... Are any of them worth it?" :

Est-ce que les « ordinateurs portables de marque Linux » en valent la peine ? J'ai vu qu'ils offraient des machines avec d'excellentes spécifications pour mon cas d'utilisation, mais j'ai aussi lu de nombreuses plaintes sur la construction fragile et bon marché.

Est-ce que l'une de ces marques propose quelque chose de durable, pas quelque chose de plastique ou de bon marché ?
J'aimerais vraiment soutenir ces entreprises si elles peuvent apporter tout ce qu'il faut au jeu. J'aime le support Linux. Je vois qu'ils offrent de bons composants, parfois évolutifs. Je suis juste préoccupé par la qualité de construction.
J'ai aussi entendu de mauvaises critiques sur l'autonomie de la batterie. Est-ce que j'ai de la chance de voir toutes les critiques et tous les posts pleurer sur la qualité de construction et que ce n'est pas un problème, ou est-ce que je devrais juste acheter un XPS, ou un Thinkpad ?

source

Je me pose les mêmes questions 🙂.

Je connaissais déjà Framework (USA) et System76 (USA). Il y a quelques semaines, j'ai découvert le fabricant espagnol basé à Valence nommé Slimbook (company).

Dans ce thread, #JaiDécouvert l'existence des fabricants suivants :

• Malibal (USA)
• Starlabs (Company) (UK)
• et Tuxedo (DE)

J'ai très bien conscience que ces laptops sont fabriqués par des Original design manufacturer (https://en.wikipedia.org/wiki/Original_design_manufacturer).

Par exemple, je lis ici que les laptop Framework sont fabriqués par Compal Electronics (https://en.wikipedia.org/wiki/Compal_Electronics), une entreprise taïwanaise, qui fabrique entre autres des laptop pour Lenovo, DELL, etc.

Je me suis intéressé à Tuxedo et en particulier le modèle Tuxedo Infinity Flexible 14 Gen 1.

Le modèle suivant est à 1067 € TTC :

• Intel Core i5-1335U (10 Cores | 12 Threads | Max. 4.6 GHz | 12 MB Cache | 15 W TDP)
• 16 GB (2x 8GB) 3200MHz CL22 Samsung
• Touch Display | non-glare | WUXGA 1920 x 1200 | 16:10 | 400nits | Stylus MPP2.0
• 500 GB Samsung 980 (NVMe PCIe 3.0)
• FRENCH (FR AZERTY) with backlit with TUX super-key
• Intel Wi-Fi 6E AX211 (802.11ax | 2.4, 5 & 6 GHz | Bluetooth 5.3)
• USB to LAN Adapter - USB-C & -A - 1GBit USB3.0
• USB-C wall mount charger | 100 Watt | EU, UK, US, AU Power Plug
• 2 years warranty (Incl. parts, labour & shipping)

Concernant le chassis, je lis :

D'une hauteur totale de moins de 2 cm, le tout premier PC convertible de TUXEDO accueille deux types d'appareils dans un seul boîtier : Ordinateur portable et tablette. Le premier convertible à voir le jour dans le monde Linux est livré dans un boîtier partiellement en aluminium argenté, les surfaces extérieures (couvercle et coque inférieure) étant fabriquées dans ce métal stable mais léger pour un transport en toute sécurité.

source

Difficile de se faire un avis avec une photo.

Autre élément qui m'intéresse fortement, c'est la possibilité d'imprimer un layout custom de clavier 😮. C'est la première fois que je rencontre cette possibilité. Je pourrais enfin pouvoir avoir un layout bepo sur laptop 🙂.

Par le passé, j'avais lu des threads à ce sujet dans le forum de Framework : custom layout

We therefore provide you with the option to customize your TUXEDO to your personal taste thanks to high-quality logo or photo printing as well as custom keyboard laser etching. Get creative and create your unique TUXEDO notebook!

source

Autre élément sympathique, il est aussi possible de customiser le capot du laptop :

Individual keyboard laser etching and logo printing.

source

Tuxedo met à disposition des drivers supplémentaires packagés pour Fedora :

TUXEDO Computers offers a well-maintained repository for Fedora Linux to install additional software such as keyboard drivers or the TUXEDO Control Centre. The repository is to be found on our server.

source

Suite à la lecture de toutes ces informations, je suis très tenté de tenter l'achat d'un Infinity Flexible 14 - Gen 1 pour le Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora".

J'ai pris le temps de lire un maximum de commentaires à propos de Tuxedo sur linuxhardware, hackernews. Pour le moment, mon sentiment est positif. J'ai vu quelques commentaires négatifs et beaucoup de commentaires positifs.

J'ai effectué des recherches sur Hardware for Linux https://linux-hardware.org/?view=computers&vendor=TUXEDO et je n'ai pas trouvé de données pour le modèle Infinity Flexible 14 - Gen 1.

Je viens de poster la question suivante sur le Subreddit de Tuxedo et sur sa page de contact de support : Can you execute hw-probe on InfinityFlex 14 Gen1 to upload data to linux-hardware.org ?.