Initial commit
This commit is contained in:
@@ -0,0 +1,100 @@
|
||||
---
|
||||
date: '2021-10-09'
|
||||
title: Stocker ses fichiers dans des dépôts git
|
||||
---
|
||||
|
||||
> En résumé : j'utilise [_git-lfs_](https://git-lfs.github.com) pour stocker
|
||||
> tous mes documents personnels, administratifs, photos, musiques, vidéos, et
|
||||
> ça convient bien **à mon usage**.
|
||||
|
||||
## Contexte
|
||||
|
||||
J'aimerais bien me passer de [Syncthing](https://syncthing.net/), et depuis que
|
||||
j'ai abandonné mon NAS Synology, je ne trouve aucune solution de synchronisation
|
||||
de fichiers équivalente à [Synology Drive](https://www.synology.com/en-us/dsm/feature/drive).
|
||||
|
||||
- [Nextcloud](https://nextcloud.com/) : franchement, je ne sais pas comment ce truc tourne. Encore une monstruosité PHP que [je range aux côtés de Wordpress et Prestashop](/interets/informatique/2021/03/14/ecommerce-et-auto-hebergement/). Ça me désespère en tant que développeur PHP... La synchronisation des fichiers est lente (Webdav...) et foireuse (il n'aime pas les fichiers préfixés par un point, trop longs, etc.), sans parler de la lourdeur du truc côté serveur (autant niveau base de données qu'espace disque), les mises à jour où il faut faire une offrande aux dieux pour qu'elles passent (et que les plugins suivent). Le client est probablement le pire que j'ai testé.
|
||||
- [Seafile](https://www.seafile.com/en/home/) : je suis à peu près certain que c'est ce qui sert de base à Synology Drive, donc théoriquement ça aurait pu me convenir, mais le système de stockage en backend n'est pas portable ; il faut passer à la version "Pro" pour stocker les fichiers dans un backend S3, et le montage de volumes via _fuse_ semble compliqué/lourd. En plus, j'ai trouvé que les performances de synchronisation n'étaient pas folichonnes (mais pas catastrophiques non plus).
|
||||
- Syncthing : options par défaut qui ne me conviennent pas, re-synchro chiante à cause des ID de machine qui changent dès qu'on fait un pet de travers, essaye un peu trop de communiquer avec l'extérieur à mon goût. Synchro relativement rapide par contre.
|
||||
|
||||
À l'exception de mes projets de dev, qui sont de toute façon dans des dépôts
|
||||
git, mes autres documents ne changent pas fréquemment. Donc finalement, je
|
||||
réalise qu'avoir un outil qui tourne en permanence en tâche de fond ne m'est pas
|
||||
vraiment indispensable. La synchro m'intéresse pour les images ou la musique,
|
||||
mais je les modifie tellement rarement qu'une synchro en temps-réel n'est pas
|
||||
pertinente ; je peux me permettre de faire un `git pull` de temps en temps...
|
||||
|
||||
## La solution : git-lfs
|
||||
|
||||
Ça fait longtemps que je réfléchi à la question, lu quantité d'articles traitant
|
||||
du sujet, tant en provenance de partisans que de détracteurs, quoique ces
|
||||
derniers se font de plus en plus rares. De toute façon, je ne risque pas grand
|
||||
chose à essayer alors voilà : je vais désormais stocker **tous** mes documents
|
||||
dans des dépôts git.
|
||||
|
||||
En ce qui me concerne, je ne vois que des avantages :
|
||||
|
||||
- j'utilise déjà git pour mes projets de dev, j'ai donc déjà toute l'infrastructure sous la main
|
||||
- même si ce n'était pas le cas, je peux utiliser n'importe quel hébergeur de services git (mais bon, je parle de mes documents personnels que je préfère donc garder dans mon réseau local...)
|
||||
- je peux garder une trace de l'historique de modification de tous mes fichiers, plus seulement de mes projets dev
|
||||
- l'extension [_lfs_](https://git-lfs.github.com) est faite pour stocker des gros fichiers (et nativement supportée par [Gitea](https://gitea.io/en-us/)), et me semble donc adéquate pour la musique, les vidéos, les photos RAW
|
||||
- je me passe d'un processus qui tourne en arrière-plan, autant côté client que côté serveur (dans la mesure où j'ai de toute façon un serveur git qui tourne) - je peux même me passer d'une autre méthode d'accès à mes fichiers, et donc virer samba/NFS/whatever
|
||||
- si un jour je ressens à nouveau le besoin d'une synchro en temps-réel, je peux me tourner vers [SparkleShare](https://www.sparkleshare.org) **sans rien changer** à mes habitudes
|
||||
- je trouve que la sauvegarde et la restauration de mes fichiers en cas de pépin est beaucoup plus simple que les procédures habituelles, et c'est dû au fonctionnement-même de git : si j'ai un grave problème sur une des machines clientes, il existe toujours au moins une copie de mes fichiers sur le réseau (sur le serveur et/ou sur les autres clients). Et si le serveur git nécessite une restauration, j'ai les dépôts répartis sur les machines clientes, il n'y a qu'à faire des `git push`.
|
||||
- Gitea (et les autres forges logicielles) intègre nativement la prévisualisation des PDF ou des images, l'écoute des fichiers audio, la lecture des fichiers vidéos, etc. Pratique pour un accès occasionnel sans cloner tous les documents ! S'il y avait aussi des éditeurs pour les fichiers OpenDocument, je serai comblé !
|
||||
- en bonus, si j'ai envie de m'amuser, je pourrais utiliser [Drone-CI](https://www.drone.io) et là c'est tout un monde qui s'ouvre à moi : automatisation d'export de mes photos dans un format adapté au web, conversion automatique de fichiers, génération automatique de documents via pandoc, etc. ; ces exemples me concernent directement et me trottent dans la tête depuis longtemps pour mes cas d'usage, mais j'imagine qu'il y en aurait bien d'autres... rien que le fait d'écrire ça fait naitre tout un tas d'idées : tags automatique sur les musiques, suppression de certains en-têtes EXIF sur certaines photos, etc.
|
||||
|
||||
Et comme je teste ça depuis quelques jours, je peux déjà constater que ça
|
||||
fonctionne mieux que ce que j'espérais, en particulier en ce qui concerne la
|
||||
synchronisation de beaucoup de fichiers de taille réduite (typiquement, de
|
||||
vieilles photos en jpeg dans des résolutions inférieures à 1920x1080).
|
||||
Habituellement, c'est ce qui pose le plus de problèmes aux autres solutions de
|
||||
stockage que j'ai testé, y compris via samba. Le débit s'effondre assez vite
|
||||
dans un tel cas de figure. git est d'office optimisé pour gérer de nombreux
|
||||
petits fichiers, et heureusement lfs ne vient pas plomber ces optimisations.
|
||||
|
||||
Dans l'exemple d'environ 5000 fichiers de moins de 5Mo, j'ai un débit constant
|
||||
de 85Mo/s au minimum sur une connexion gigabit (dont le maximum théorique est
|
||||
donc de 125Mo/s). De fait, la synchro est _très_ rapide, beaucoup plus que via
|
||||
webdav par exemple... Je peux donc rajouter la **rapidité** à ma liste
|
||||
d'avantages.
|
||||
|
||||
Enfin, dernier avantage et non des moindres, c'est que c'est **très simple** à
|
||||
mettre en place. Il n'y a qu'à informer lfs des types de fichiers qu'il doit
|
||||
gérer :
|
||||
|
||||
```shell {linenos=false,class=not-prose}
|
||||
git lfs track "*.pdf" # Pour stocker les PDF dans lfs...
|
||||
```
|
||||
|
||||
Cette commande aura pour effet de créer un fichier _.gitattributes_ (qu'il est
|
||||
aussi possible de modifier manuellement), et c'est ce fichier que git va
|
||||
utiliser pour déterminer les fichiers à stocker dans lfs. Tout le reste se fait
|
||||
via les commandes git classiques.
|
||||
|
||||
## Inconvénients
|
||||
|
||||
Si ça vous gonfle de faire un `git commit` et `git push` à chaque fois que vous
|
||||
modifiez un fichier et de faire un `git pull` sur les autres machines sur
|
||||
lesquelles vous voulez synchroniser vos fichiers, c'est sûr que cette solution
|
||||
ne vous conviendra pas, mais n'oubliez pas que SparkleShare peut faire tout ça
|
||||
pour vous.
|
||||
|
||||
Je pense que l'utilisation de git pour stocker ses documents personnels
|
||||
nécessite une bonne organisation pour être optimale. J'ai créé un certain nombre
|
||||
de dépôts, pour les musiques, pour les vidéos, pour les photos, pour les fonds
|
||||
d'écran, pour les documents administratifs, pour les documents professionnels,
|
||||
etc. Si on n'est pas habitué à git, ça peut être intimidant de jongler avec tout
|
||||
ça. On peut très bien fonctionner avec un seul dépôt ceci-dit, peut être que
|
||||
j'ai fait de l'[_overengineering_](https://en.wikipedia.org/wiki/Overengineering)...
|
||||
|
||||
Une "limitation" de lfs qui ne me concerne pas mais dont il faut être conscient :
|
||||
|
||||
> Why doesn’t Git LFS handle files larger than 4 GiB on Windows?
|
||||
>
|
||||
> Git LFS itself handles these files just fine. However, Git LFS is usually invoked by Git, and Git itself on Windows doesn’t handle files using smudge and clean filters (like Git LFS) that are larger than 4 GiB. As soon as Git handles this, Git LFS will work with it automatically.
|
||||
>
|
||||
> In the mean time, you can set the environment variable GIT_LFS_SKIP_SMUDGE to 1 and run git lfs pull to pull down the LFS files. This bypasses Git’s smudging functionality and therefore avoids its limitations.
|
||||
|
||||
De manière générale, lisez la [FAQ](https://github.com/git-lfs/git-lfs/wiki/FAQ)
|
||||
et le reste du [wiki](https://github.com/git-lfs/git-lfs/wiki) de lfs.
|
||||
@@ -0,0 +1,200 @@
|
||||
---
|
||||
date: '2021-10-20'
|
||||
title: 'Réflexion : Dead-man switch'
|
||||
---
|
||||
|
||||
## Définition
|
||||
|
||||
Un _dead-man switch_ est une procédure exécutée à la mort d'une personne. Dans
|
||||
la culture populaire, il s'agit généralement d'un capteur biométrique : si son
|
||||
porteur décède, ce capteur déclenche un évènement particulier (généralement,
|
||||
l'explosion d'une bombe ou l'effacement de données dont le monde dépend...).
|
||||
|
||||
Historiquement, il s'agit d'un dispositif utilisé dans le domaine ferroviaire
|
||||
permettant de s'assurer de l'état de conscience du conducteur du train ou du
|
||||
métro, puis étendu à d'autres domaines. On trouve un tel dispositif dans les
|
||||
véhicules modernes.
|
||||
|
||||
## Application numérique au "commun des mortels"
|
||||
|
||||
La question de l'advenir des données personnelles lors du décès d'un individu a
|
||||
notamment été posée dans le cadre de l'usage de facebook ou de twitter. Quand le
|
||||
propriétaire d'un compte de réseau social décède, qui peut réclamer le contenu
|
||||
publié ? Le sujet est d'autant plus intéressant que de nombreux domaines sont
|
||||
concernés, pas seulement les données personnelles : comment attester de la
|
||||
légitimité de la demande d'accès au compte, comment attester du décès réel du
|
||||
porteur initial, que se passe-t'il si le prétend défunt ne l'est pas, quel est
|
||||
le motif de la demande d'"héritage", etc. Les problématiques sont nombreuses, et
|
||||
je pense que les "plateformes" seules ne peuvent pas les résoudre. Je pense
|
||||
qu'il appartient à chaque individu de prendre ses dispositions s'il souhaite que
|
||||
ses données lui survive, et pas seulement sur les réseaux sociaux, au même titre
|
||||
que l'on organise "matériellement" sa fin de vie - lorsque c'est possible.
|
||||
|
||||
Malheureusement, organiser sa fin de vie numérique s'oppose à la technicité de
|
||||
l'outil informatique. Même pour un geek avisé, la tâche est colossale, à cause
|
||||
de la quantité de choses auxquelles il faut penser. Non pas qu'organiser sa fin
|
||||
de vie soit facile _IRL_, mais le regroupement de l'ensemble des informations
|
||||
publiées sur Internet au cours de la vie d'un individu n'est pas aussi facile
|
||||
qu'on pourrait le penser.
|
||||
|
||||
Nous arriverons à plus ou moins courte échéance au moment où Internet verra une
|
||||
génération complète à la fois commencer et terminer sa vie en ligne. Ce n'est
|
||||
pas encore le cas, et même si de temps en temps on nous propose une piqûre de
|
||||
rappel, on est tous encore loins de planifier notre fin de vie numérique.
|
||||
|
||||
## Pourquoi planifier sa fin de vie numérique ?
|
||||
|
||||
Permettez-moi de vous poser la question autrement : pourquoi planifions-nous
|
||||
généralement notre fin de vie ? Il n'y a pas qu'une seule réponse, mais on peut
|
||||
raisonnablement penser que deux raisons au moins parmi d'autres nous y pousse :
|
||||
|
||||
- la pérennisation des richesses familiales
|
||||
- les croyances individuelles
|
||||
|
||||
Il y a de nombreux autres cas de figure évidemment, que l'on ait des héritiers
|
||||
ou non, des richesses ou non, des croyances ou non.
|
||||
|
||||
Mon point de vue est que l'on ne pose pas la question aux gens "pourquoi
|
||||
planifiez-vous votre fin de vie ?" ; on ne s'intéresse qu'aux dispositions
|
||||
pratiques. On part même du principe que tout le monde, par défaut, veut
|
||||
organiser sa fin de vie, ultime contrôle sur nos existences. Alors pourquoi
|
||||
poser la question de la planification de la fin de vie numérique, et ne pas,
|
||||
tout simplement, partir du principe que toute personne doit pouvoir disposer de
|
||||
toute donnée numérique qu'elle a pu produire au cours de sa vie ?
|
||||
|
||||
## De fortes contraintes techniques
|
||||
|
||||
De par la volatilité d'une donnée numérique, il est presqu'impossible d'en
|
||||
garantir l'existence pour une durée prolongée. J'ai fait mes débuts sur Internet
|
||||
sur MSN Communities, et MSN Chat. Je suis aussi intervenu sur Caramail, fut un
|
||||
temps. Un jour, sites parmi les plus visités du monde. Aujourd'hui, complètement
|
||||
tombés dans l'oubli. Pas que leurs noms : leurs données aussi, y compris celles
|
||||
que j'y ai mises. Impossible pour moi de prouver que j'ai obtenu une marque de
|
||||
reconnaissance de la part de Microsoft pour la qualité des communautés que j'ai
|
||||
créé sur MSN Communities. Impossible de retrouver des informations que j'ai pu y
|
||||
publier, et même la [Wayback Machine](https://archive.org/web/) n'y peut rien, à
|
||||
plus forte raison lorsque le contenu a été publié dans un espace qui demande une
|
||||
authentification.
|
||||
|
||||
Malgré tous les efforts que je peux y mettre, (et je me considère techniquement
|
||||
avancé) il m'est impossible de rassembler tout ce que j'ai produis au cours de
|
||||
ma vie numérique. Et croyez bien que je le regrette. Et ce n'est pas
|
||||
nécessairement parce que j'ai consciemment supprimé ces données : disparition du
|
||||
domaine, voire du site complet, sur lequel les données ont été publiées,
|
||||
utilisation d'un pseudonyme oublié, commentaire isolé sur un site de niche,
|
||||
redirections infructueuses, les raisons pour lesquelles on peut ne pas remettre
|
||||
la main sur ses données sont nombreuses, et souvent indépendantes de notre
|
||||
volonté.
|
||||
|
||||
## _Dead-man switch_ moderne ?
|
||||
|
||||
Si la technologie existe pour surveiller l'état de santé d'un individu (via les
|
||||
bracelets ou montres connectés, les téléphones portables, ou les dispositifs à
|
||||
destination des personnes âgées), elle se contente de prévenir quelqu'un, qu'il
|
||||
s'agisse des secours ou d'un proche, mais elle est encore bien incapable de
|
||||
s'occuper de sa vie numérique.
|
||||
|
||||
Comme je le disais plus haut, pour le moment, seul l'individu peut choisir ce
|
||||
qu'il veut faire de ses données lors de son trépas. Certaines plateformes ont
|
||||
mis en place diverses actions à ce titre, mais chaque individu doit bien penser
|
||||
à activer ces options, sachant qu'elles ne peuvent pas toujours être déclenchées
|
||||
automatiquement.
|
||||
|
||||
Il y a tellement de plateformes différentes sur lesquelles on publie du contenu
|
||||
au cours de sa vie numérique qu'il est impossible de s'en souvenir en
|
||||
intégralité. De plus, il est impossible de relier avec certitude une donnée
|
||||
particulière avec un auteur particulier. Des protocoles tels qu'ActivityPub, et
|
||||
les solutions auto-hébergés restent la meilleure option à l'heure actuelle pour
|
||||
conserver la main sur ses données, et le sujet a été amplement abordé par mes
|
||||
pairs. Mais même en mettant en oeuvre de telles solutions, il n'existe pas
|
||||
d'architecture commune, de protocoles, d'interfaces permettant des actions
|
||||
universelles en cas de fin de vie numérique. Rien, en tout cas, d'uniformisé,
|
||||
documenté. Les plus geeks d'entre nous auront bien quelques idées, mais elles
|
||||
sont loin, très loin d'être accessibles au commun des mortels.
|
||||
|
||||
## Que doit faire un _dead-man switch_ ?
|
||||
|
||||
Dans l'absolu, un _DMS_ devrait être informé en temps réel de l'intégralité des
|
||||
données produites par un individu : aussi bien le contenu que les méta-données
|
||||
et leur emplacement numérique (l'URL pour y accéder), avec un horodatage. Cela
|
||||
ressemble à s'y méprendre à ce que fait _git_... qui représente justement, selon
|
||||
moi, le meilleur outil pouvant servir à la réalisation d'un _DMS_.
|
||||
|
||||
En admettant que le _DMS_ dispose de ces informations, il doit pouvoir les
|
||||
stocker de façon fiable pendant au moins la durée de vie de l'individu. Si vous
|
||||
êtes un geek, vous disposez sûrement de sauvegardes datant de plusieurs années.
|
||||
Peut-être même, une ou deux dizaines. Si vous n'êtes pas geek, il est peut
|
||||
probable que la donnée la plus ancienne que vous ayez jamais produite vous soit
|
||||
encore accessible.
|
||||
|
||||
Même si l'on se considère geek, certaines données sont de toute façon perdues à
|
||||
jamais. Comment pourrais-je transférer sur un ordinateur moderne les programmes
|
||||
que j'ai écrits en BASIC dans les années 80, stockés sur des disquettes dont le
|
||||
format n'a jamais été créé pour autre chose qu'un Amstrad CPC 464 ou 6128 ? Je
|
||||
devrais déployer des trésors d'ingéniérie pour y parvenir, si tant est que je
|
||||
pouvais remettre la main sur une telle machine en état de marche, et surtout,
|
||||
sur les disquettes dont il est question...
|
||||
|
||||
En outre se pose aussi la question des formats de données : des formats binaires
|
||||
qui existaient dans les années 80 ne sont probablement plus lisibles
|
||||
aujourd'hui, sauf, encore une fois, pour les plus opiniâtres des geeks.
|
||||
|
||||
Un bon _DMS_ doit stocker ses données dans un format reproductible et pérenne,
|
||||
et doit donc trouver un compromis entre l'espace nécessaire au stockage de la
|
||||
donnée et son interopérabilité. On doit pouvoir _lire_ la donnée même si son
|
||||
format initial n'est plus supporté. Là encore, c'est un sujet que la philosophie
|
||||
de l'informatique a abordé assez souvent, sans pour autant trouver de réelle
|
||||
solution. Dans l'absolu, l'intégration d'émulateurs pourrait permettre la
|
||||
reproduction de données trop anciennes, mais aurait sans doute un coût matériel
|
||||
prohibitif.
|
||||
|
||||
Si l'on dispose des informations de base et d'un moyen de stockage fiable, il
|
||||
faut décider ensuite quoi faire de ces données. Un _DMS_ doit offrir le moyen
|
||||
de définir des règles précises, des tâches particulières à effectuer lors du
|
||||
déclenchement de la procédure de fin de vie. Telles données doivent être rendues
|
||||
disponibles à telle ou telle personne uniquement, telles données doivent être
|
||||
rendue publiques à tel endroit, tel message doit être envoyé à telle personne,
|
||||
etc. Là encore, la complexité de la gestion de ces données pourrait
|
||||
littéralement occuper une vie entière.
|
||||
|
||||
Enfin, il faut disposer d'un moyen de déclencher ces procédures, au moment
|
||||
"opportun". Les technologies de surveillance individuelle de santé peuvent y
|
||||
aider, mais la criticité d'une telle procédure recquiert un comportement sans
|
||||
faille. En outre, il faut que le _DMS_ soit disponible au moment où se produit
|
||||
le décès, c'est-à-dire que toute la chaîne logicielle soit fonctionnelle. Et ce
|
||||
n'est pas toujours selon le bon vouloir de l'individu...
|
||||
|
||||
## Impossible à réaliser ?
|
||||
|
||||
Je récapitule :
|
||||
|
||||
- [x] Surveillance de l'état de santé d'un individu
|
||||
- [ ] Déclenchement sécurisé d'une action auprès du _DMS_
|
||||
- [ ] Le _DMS_ doit avoir accès à toutes les données de l'individu
|
||||
- [ ] Le _DMS_ doit lire et appliquer les règles qu'a défini l'individu de son vivant concernant chaque donnée enregistrée
|
||||
- [ ] Dans l'absolu, le _DMS_ devrait répliquer toutes les données sur un système de stockage spécifique et fournir une interface de navigation pour que les proches du défunt puisse les visualiser d'une façon ou d'une autre
|
||||
- [ ] Le _DMS_ doit pouvoir stocker ces données pendant une durée indéterminée
|
||||
- [ ] Il doit fournir les moyens de visualiser n'importe quelle donnée, même trop vieille pour des machines modernes
|
||||
- [ ] Il doit aussi embarquer des moyens modernes de visualisation de ces données qu'il sera possible d'utiliser avec des ordinateurs construits à moyen ou long terme
|
||||
|
||||
Il y a encore de nombreuses problématiques à résoudre, comme la sécurité des
|
||||
données stockées localement, la sécurité des accès aux données distantes,
|
||||
acquérir la certitude que le défunt a bien déclenché la procédure et non qu'elle
|
||||
l'ait été par une action malveillante visant spécifiquement à y accéder, la
|
||||
notarisation des règles définies par le défunt de son vivant afin de s'assurer
|
||||
du respect juridique de la transmission des données, il faudra probablement
|
||||
tenir compte des licences sous lesquelles l'individu a publié, voire appliquer
|
||||
une licence par défaut, etc.
|
||||
|
||||
Je pense que pour l'heure, on ne disposera pas d'un tel système utilisé à grande
|
||||
échelle avant un moment, et lorsqu'il le sera, il sera aux mains d'une grande
|
||||
entreprise privée. Probablement facebook, peut-être qu'Apple offrira un service
|
||||
similaire. Google sans aucun doute, considérant sa volonté de [tuer la mort](https://en.wikipedia.org/wiki/Calico_(company))
|
||||
et son omnipotence légendaire. Mais, si on est sur toutes ces plateformes, on
|
||||
va multiplier les _DMS_, rendant la procédure encore plus compliquée.
|
||||
Alors on verra peut-être naitre des services hybrides, interconnectés, et puis
|
||||
enfin, quelques années plus tard, des solutions Libres et auto-hébergeables.
|
||||
|
||||
On verra bien. J'aimerais bien disposer de tels services Libres et
|
||||
auto-hébergables dès aujourd'hui, parce que leur prise en main va prendre un
|
||||
temps considérable.
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
date: '2021-10-26T17:54:56+01:00'
|
||||
title: Pour le bien de vos écrans, investissez dans vos câbles
|
||||
---
|
||||
|
||||
Très heureux détenteur de deux écrans Alienware AW2518HF et AW2521HF, que j'ai
|
||||
choisi principalement pour leur fréquence d'affichage de 240Hz, je me retrouvais
|
||||
frustré quand, passant au Mac mini depuis le laptop du travail ou depuis le PC
|
||||
dédié au jeu, j'étais dans l'incapacité de monter au-delà de 120/144Hz. Pour
|
||||
moi, la cause était à chercher soit dans la connectique, dans le sens où "là je
|
||||
suis en HDMI, c'est le HDMI qui me bride à 120Hz, là je passe par un adaptateur
|
||||
USB-C, c'est l'adaptateur qui me bride", soit le Mac mini M1 qui était incapable
|
||||
de piloter les deux écrans en 240Hz. À l'époque où j'ai fait mon installation,
|
||||
on ne disposait pas encore d'informations précises à ce sujet.
|
||||
|
||||
En pratique, ma connectique se présentait de la façon suivante :
|
||||
|
||||
- Mac mini :
|
||||
- HDMI vers HDMI sur le 2518, bridé à 120Hz (câble Amazon Basic estampillé 4K/60Hz)
|
||||
- USB-C vers HDMI sur le 2521, bridé à 144Hz (câble d'entrée de gamme Choetech 4K/60Hz)
|
||||
- Laptop du travail :
|
||||
- HDMI vers HDMI sur le 2518, 240Hz (câble Amazon Basic estampillé 4K/60Hz)
|
||||
- PC de jeu :
|
||||
- DisplayPort vers DisplayPort sur le 2518, 240Hz (câble haut de gamme 4K/60Hz)
|
||||
|
||||
En outre, sur le Mac mini (et seulement sur le Mac mini), je trouvais que le
|
||||
2521 était comme délavé, et surtout, de temps en temps, l'image "brûlait"
|
||||
l'écran, c'est-à-dire que si je changeais d'image, l'image précédente restait
|
||||
comme "incrustée". Je pensais que c'était un défaut de fabrication, ou que
|
||||
c'était un bug logiciel ou matériel du Mac mini M1, et comme le soucis n'était
|
||||
ni fréquent ni permanent, je ne voyais pas de raison de m'inquiéter plus que ça.
|
||||
|
||||
Il faut également préciser que j'étais quelque peu "formaté" par tous ces
|
||||
articles vus sur le web, clamant que finalement, il n'y avait pas de raison de
|
||||
dépenser des fortunes pour les câbles HDMI ou DisplayPort, que les câbles
|
||||
d'entrée de gamme étaient tout aussi efficaces.
|
||||
|
||||
Mais à l'occasion de mon anniversaire, j'ai souhaité monter en gamme sur la
|
||||
connectique vidéo du Mac mini. J'ai donc découvert que mes problèmes étaient à
|
||||
100% dus à la qualité médiocre des câbles que j'utilisais jusqu'alors. Je
|
||||
n'avais pas vraiment de raisons de douter des câbles Amazon Basics : celui du
|
||||
laptop, acheté en même temps que celui du Mac mini, ne me bride en aucune façon.
|
||||
Pas plus que d'autres câbles de la marque que j'utilise ailleurs.
|
||||
|
||||
Non seulement j'ai maintenant du 240Hz sur mes deux écrans, peu importe
|
||||
l'ordinateur sur lequel je me trouve, mais en plus j'ai une meilleure
|
||||
colorimétrie et je n'ai plus ce problème d'image "brûlée". Ma connectique se
|
||||
présente désormais ainsi :
|
||||
|
||||
- Mac Mini :
|
||||
- HDMI vers HDMI sur le 2521, 240Hz (câble haut de gamme **8K**/60Hz)
|
||||
- USB-C vers HDMI sur le 2518, 240Hz (câble haut de gamme 4K/60Hz)
|
||||
- Laptop du travail :
|
||||
- HDMI vers HDMI sur le 2518, 240Hz (câble haut de gamme **8K**/60Hz)
|
||||
- USB-C vers DisplayPort sur le 2521, 240Hz (câble haut de gamme **8K**/60Hz)
|
||||
- PC de jeu :
|
||||
- DisplayPort vers DisplayPort sur le 2518, 240Hz (câble haut de gamme 4K/60Hz)
|
||||
|
||||
Si le 8K est plus commercial qu'autre chose, au moins je m'assure d'avoir de la
|
||||
marge. Si un câble est certifié 8K/60Hz, je pourrais envisager plus tard
|
||||
d'acheter un écran 4K/144Hz, et je suis certain d'avoir du 240Hz en 1920x1080.
|
||||
|
||||
Je pense désormais que si j'avais continué à utiliser le câble Choetech, j'aurai
|
||||
fini par définitivement cramer mon 2521.
|
||||
|
||||
En conclusion : n'hésitez pas à prendre le haut du panier en matière de câbles,
|
||||
vous dépenserez peut-être 20 ou 30 euros de plus que si vous choisissez de
|
||||
l'entrée de gamme, mais vous éviterez de cramer un écran à 400 euros... sans
|
||||
compter les autres avantages : pouvoir monter en fréquence, meilleure
|
||||
colorimétrie, meilleure qualité d'image.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
date: '2021-10-26T02:52:56+01:00'
|
||||
title: Récupération d'articles d'archives
|
||||
---
|
||||
|
||||
En fouillant un peu le net et la [Wayback Machine](https://web.archive.org/),
|
||||
j'ai pu extraire quelques billets que j'avais écris en 2016. Comme ce sont les
|
||||
miens, je les ai rapatriés ici-même.
|
||||
|
||||
- 27/07/2016 - [Alphabet, une entreprise pas comme les autres](/interets/informatique/2016/07/27/alphabet-une-entreprise-pas-comme-les-autres/)
|
||||
- 02/08/2016 - [Protection de la vie privée et conspirationnisme](/interets/informatique/2016/08/02/protection-de-la-vie-privee-et-conspirationnisme/)
|
||||
- 10/08/2016 - [De l'inutilité et de l'hypocrisie d'AdBlock Plus](/interets/informatique/2016/08/10/de-l-inutilite-et-de-l-hypocrisie-d-adblock-plus/)
|
||||
|
||||
J'ai également trouvé un vieux site
|
||||
que j'avais fait en PHP avec la platforme e107, pour présenter quelques outils
|
||||
que j'avais développé en 2004. Il est intéressant de noter la mention d'une
|
||||
application appelée "Bookmarks Manager", qui deviendra
|
||||
"[Cyca](https://git.dern.ovh/richard/cyca)" quelques années plus tard...
|
||||
|
||||
En remontant le temps encore plus loin, je suis arrivé sur la
|
||||
[communauté MSN](https://web.archive.org/web/20080405051026/http://groups.msn.com/LeparadisInformatique/chronologieduparadis.msnw)
|
||||
dont [je vous ai déjà parlé](/interets/informatique/2021/10/20/reflexion-dead-man-switch/#de-fortes-contraintes-techniques).
|
||||
Et là mon coeur s'est emballé au rappel de cette esthétique si particulière,
|
||||
cette interface, ces gens que j'ai connu, avec qui j'ai vécu des moments forts,
|
||||
parfois. Et qui ensuite ont disparu sans garder contact, lors de la dissolution
|
||||
de MSN Communities. Une des meilleures des pays francophones, qui m'a valu un
|
||||
papillon MSN, marque de reconnaissance sans valeur financière mais tellement
|
||||
importante quand on est un geek de 19 ans... Le "Paradis Informatique" sur MSN,
|
||||
c'était moi... J'ai du mal à croire que ce n'était qu'il n'y a que 20 ans !
|
||||
|
||||
Si je trouve d'autres de mes vieux articles, je les importerai. Mais comme il
|
||||
est difficile de trouver le squelette complet d'un dinosaure, il risque d'être
|
||||
compliqué de retrouver l'intégralité de mes publications faites après
|
||||
MSN Communities.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
date: '2021-10-27'
|
||||
title: 'Aphorisme #1'
|
||||
---
|
||||
|
||||
Les assistants vocaux tels que Siri font une aide quotidienne formidable. Ils
|
||||
présentent néanmoins un grave inconvénient : ils n'attendent pas de politesses,
|
||||
et répondront toujours, même si on ne leur dit jamais "Merci".
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
date: '2021-10-29'
|
||||
title: Déployer Hugo via Gitea et Drone-CI avec Caddy et MinIO
|
||||
---
|
||||
|
||||
Si le titre de cet article vous est familié : MERCI ! cela signifie que vous me
|
||||
lisez 😄 Dans le cas contraire, cet article fait suite à un autre article publié
|
||||
le mois dernier : [Déployer Hugo via Gitea et Drone-CI](/interets/informatique/2021/09/12/deployer-hugo-via-gitea-et-drone-ci/).
|
||||
Vous aurez donc compris que je vais rendre la procédure encore plus complexe.
|
||||
|
||||
<details class="read-more"><summary>Voir aussi</summary>
|
||||
|
||||
- [/interets/informatique/2021/09/12/deployer-hugo-via-gitea-et-drone-ci/](/interets/informatique/2021/09/12/deployer-hugo-via-gitea-et-drone-ci/)
|
||||
|
||||
</details>
|
||||
|
||||
## Contexte et motivation
|
||||
|
||||
Je suis très satisfait de ma stack de publication actuelle : j'écris mes
|
||||
articles "localement" sur mon Mac mini, quand je suis satisfait je commit mes
|
||||
modifications sur mon serveur Gitea, Drone-CI se déclenche, compile le site,
|
||||
et le copie sur le serveur web via SSH. Pour servir le site, j'utilise Caddy,
|
||||
qui doit alors disposer d'un accès au système de fichiers du serveur.
|
||||
|
||||
J'aimerais supprimer cette dépendance, pour m'éviter de monter un volume docker
|
||||
rien que pour faire ça. Il y a d'autres raisons plus techniques : cela pourrait
|
||||
me simplifier les sauvegardes, rendre possible la réplication des données, ce
|
||||
qui pourrait amèner à de la haute-disponibilité. Et puis, je suis très satisfait
|
||||
des performances de mon serveur MinIO mais qui, pour l'instant, reste
|
||||
sous-exploité. En outre, je pourrai supprimer le lien SSH entre la CI et le
|
||||
serveur Web, et l'utilisateur créé à cet unique effet.
|
||||
|
||||
Le but est donc que Drone-CI stocke le résultat de la compilation (c'est-à-dire,
|
||||
l'arborescence complète du site statique) dans MinIO, plutôt que de l'envoyer au
|
||||
serveur via SSH. Trois choses sont donc à modifier : MinIO pour créer un bucket
|
||||
destiné à mon site, Caddy pour lui dire comment accèder et servir ces données,
|
||||
et Drone-CI pour lui dire comment stocker les données dans le bucket.
|
||||
|
||||
Tout cela a l'air bien compliqué, je vous l'accorde, mais on peut voir les
|
||||
choses sous un autre angle :
|
||||
|
||||
- Je ne rajoute finalement qu'une application au processus (MinIO)
|
||||
- C'est une application extrêmement simple, populaire, légère, rapide (en upload, je sature ma liaison gigabit, peu importe la taille des fichiers envoyés, ce qui n'est pas le cas avec SSH par exemple)
|
||||
- Je supprime un accès SSH et un utilisateur, donc - petit - gain de sécurité
|
||||
- Je découple Caddy et Drone-CI du stockage disque pour les coupler à un système de stockage distant, distribué et répliqué
|
||||
|
||||
Donc au final, ajouter une étape au processus me permet de simplifier la gestion
|
||||
de toute la stack, de mes serveurs, et de pérenniser mes données. Le tout avec
|
||||
des outils simples, puissants, légers et performants. Que demander de plus ?
|
||||
|
||||
## MinIO
|
||||
|
||||
Avec un MinIO déjà opérationnel, il suffit de créer un nouvel utilisateur, un
|
||||
nouveau bucket (avec l'attribut `public`, sinon Caddy ne pourra pas y accéder),
|
||||
et donner les permissions `readwrite` au nouvel utilisateur sur ce bucket.
|
||||
C'est extrêmement simple via l'interface web.
|
||||
|
||||
J'ai nommé mon bucket _richard-dern.fr_.
|
||||
|
||||
## Drone-CI
|
||||
|
||||
Dans Drone-CI, il faut créer deux nouveaux secrets, dans lesquels on va mettre
|
||||
l'*access_key* du nouvel utilisateur dans MinIO, et la *secret_key*
|
||||
correspondante. J'ai tout simplement nommé ces secrets respectivement
|
||||
*s3_access_key* et *s3_secret_key*.
|
||||
|
||||
Dans le fichier _.drone.yml_ de mon projet, j'ai remplacé la partie concernant
|
||||
SCP par le plugin S3 :
|
||||
|
||||
```yaml {class=not-prose}
|
||||
- name: upload
|
||||
image: plugins/s3
|
||||
settings:
|
||||
bucket: richard-dern.fr # Remplacez par le nom de votre propre bucket
|
||||
source: public/**/*
|
||||
target: /
|
||||
strip_prefix: public/ # On supprime public/ sinon c'est chiant
|
||||
path_style: true # Obligatoire pour MinIO, déprécié chez AWS
|
||||
access_key:
|
||||
from_secret: s3_access_key # Le nom de votre nouvel utilisateur MinIO
|
||||
secret_key:
|
||||
from_secret: s3_secret_key # La secret_key correspondante
|
||||
endpoint: http://10.0.2.1:9000 # Remplacez par l'URL de votre MinIO
|
||||
```
|
||||
|
||||
## Caddy
|
||||
|
||||
Caddy a nécessité un peu plus de recherche, mais j'ai fini par trouver une façon
|
||||
de faire, sans avoir recours au moindre plugin. Remplacez, dans les lignes
|
||||
suivantes (2 à 7), _richard-dern.fr_ par le nom de votre bucket, et la dernière
|
||||
ligne par l'adresse de votre serveur MinIO.
|
||||
|
||||
``` {class=not-prose}
|
||||
www.richard-dern.fr {
|
||||
# Site statique, donc on bloque tout ce qui n'est pas GET
|
||||
# On évite ainsi les requêtes à l'API MinIO
|
||||
@@method not method GET
|
||||
error @@method "Method not allowed" 405
|
||||
|
||||
@@dirregex {
|
||||
path_regexp static ^(.*)/$
|
||||
}
|
||||
|
||||
rewrite @@dirregex /richard-dern.fr{re.static.1}/index.html
|
||||
rewrite * /richard-dern.fr{path}
|
||||
reverse_proxy http://10.0.2.1:9000
|
||||
}
|
||||
```
|
||||
|
||||
Le problème avec Caddy dans ce contexte, c'est qu'il ignore `try_files` et
|
||||
`index`, et que MinIO renvoit la liste des fichiers contenus dans le répertoire
|
||||
demandé en XML (API oblige). En outre, la directive *reverse_proxy* ne peut pas
|
||||
contenir de chemin. Pour résoudre ce problème, on utilise les lignes 7 et 8, ce
|
||||
qui nous permet au moins de ne pas être redirigés vers la page de connexion de
|
||||
MinIO.
|
||||
|
||||
Pour le problème des dossiers, on défini un
|
||||
[_matcher_](https://caddyserver.com/docs/caddyfile/matchers#syntax) dans le
|
||||
jargon de Caddy, en l'ocurrence un
|
||||
[*path_regexp*](https://caddyserver.com/docs/caddyfile/matchers#path-regexp). On
|
||||
peut ainsi matcher toute URL qui se termine par un `/`. On créé ensuite la règle
|
||||
de réécriture à la ligne 6, pour ajouter `/index.html` à la fin. De fait, on
|
||||
peut conserver des URLs courtes, et, normalement, l'accès aux autres ressources
|
||||
n'est pas cassé...
|
||||
|
||||
## Conclusion
|
||||
|
||||
Et voilà ! On peut démonter le volume utilisé jusq'à présent, et supprimer les
|
||||
fichiers du disque : Caddy n'utilisera plus que MinIO pour servir mon site. Le
|
||||
gain en performances me semble très intéressant, bien qu'il soit difficilement
|
||||
mesurable pour vous, chers visiteurs, compte tenu de mon upload limité. Mais de
|
||||
mon point de vue, tout me semble aller beaucoup plus vite, en particulier quand
|
||||
il y a des images dans un article.
|
||||
|
||||
Prochaine étape : haute-disponibilité ?
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
date: '2021-10-30'
|
||||
title: Drone-CI et htmltest pour traquer les liens morts dans Hugo
|
||||
---
|
||||
|
||||
Voilà un excellent exemple de ce pourquoi j'ai une stack de publication qui peut
|
||||
sembler compliquée au premier abord mais qui, au final, permet de faire plein de
|
||||
choses sympathiques. Si vous voulez en savoir plus, je vous invite à lire les
|
||||
autres articles que j'ai écrit à ce sujet :
|
||||
|
||||
<details class="read-more"><summary>Voir aussi</summary>
|
||||
|
||||
- [/interets/informatique/2021/09/12/deployer-hugo-via-gitea-et-drone-ci/](/interets/informatique/2021/09/12/deployer-hugo-via-gitea-et-drone-ci/)
|
||||
- [/interets/informatique/2021/10/29/deployer-hugo-via-gitea-et-drone-ci-avec-caddy-et-minio/](/interets/informatique/2021/10/29/deployer-hugo-via-gitea-et-drone-ci-avec-caddy-et-minio/)
|
||||
|
||||
</details>
|
||||
|
||||
Rapidement : j'ai Drone-CI qui s'occupe de compiler et publier un site statique
|
||||
réalisé avec Hugo (le site que vous êtes en train de visiter). Je vais lui
|
||||
demander d'en faire un peu plus : parcourir le site à la recherche de liens
|
||||
morts et bloquer la mise en production tant que je ne les ai pas corrigés.
|
||||
|
||||
Il suffit de rajouter les quelques lignes suivantes dans le fichier _.drone.yml_
|
||||
du projet, dans la section _steps_ :
|
||||
|
||||
```yaml {class=not-prose}
|
||||
- name: test_links # Nom de l'étape de la CI
|
||||
image: wjdp/htmltest # Image docker utilisée
|
||||
commands:
|
||||
- htmltest public/ # Dans Drone-CI, le site Hugo compilé se trouve dans public/
|
||||
```
|
||||
|
||||
En plus de vérifier la disponibilité des URLs, [htmltest](https://github.com/wjdp/htmltest)
|
||||
peut (et va) effectuer d'autres tests utiles et pertinents. Il est possible de
|
||||
[configurer l'application](https://github.com/wjdp/htmltest#wrench-configuration)
|
||||
plus en détails, mais le comportement de base de `htmltest` me convient bien.
|
||||
|
||||
Un petit "soucis" à noter : cette étape doit survenir **après** le déploiement
|
||||
en production, faute de quoi les liens vers une page nouvellement créée mais pas
|
||||
encore déployée seront considérés comme morts. On n'empêchera donc pas les liens
|
||||
morts d'arriver en production, mais au moins la CI pourra nous alerter de leur
|
||||
présence.
|
||||
|
||||
Évidemment, ça augmente quelque peu le temps de mise en production (je passe de
|
||||
35 secondes à 3 minutes), mais au moins, plus de liens morts, en seulement
|
||||
quatre lignes de conf... Simple, pour une fois !
|
||||
Reference in New Issue
Block a user